commit 155b42bec9cbb6b8cdc47dd9bd09503a81fbe493 Author: Greg Kroah-Hartman Date: Fri Jul 24 16:21:27 2026 +0200 Linux 7.1.5 Link: https://lore.kernel.org/r/20260721152552.646164743@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Salvatore Bonaccorso Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Link: https://lore.kernel.org/r/20260722142947.085426486@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Jeffrin Jose T Tested-by: Shuah Khan Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Tested-by: Barry K. Nathan Tested-by: Takeshi Ogasawara Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Benjamin Boortz Signed-off-by: Greg Kroah-Hartman commit 872380f930c9da8e8f08837fe0dade5023ed9bca Author: Greg Kroah-Hartman Date: Sat May 30 12:29:07 2026 +0200 Revert "gpib: cb7210: Fix region leak when request_irq fails" commit 285ecb7d9e1b2401c2eccca4d0f26615f4d651eb upstream. This reverts commit 5ad28496055858166eb2268344c8fda2c26d3561. Turns out not to be correct. Link: https://lore.kernel.org/r/PpNUbGhrvT8I_KayoDvQYI2PYjmMw1QEkuVBDZz2PwBsVVgPkBXJarc2mBM0IhiH3AQG0GtgqEsDRXNj3yUKEDBaZa25u73pAjvcE6vfRsg=@protonmail.com Reported-by: Dominik Karol Piątkowski Cc: Mark Brown Cc: Hongling Zeng Cc: Hongling Zeng Signed-off-by: Greg Kroah-Hartman commit ad1cafa1bdaa71da85d71cac053838bbe97852b6 Author: Thomas Gleixner Date: Fri Jul 3 12:02:38 2026 +0200 posix-cpu-timers: Prevent UAF caused by non-leader exec() race commit 920f893f735e92ba3a1cd9256899a186b161928d upstream. Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which survived about 10 years. The fix for the workaround changed the task pointer to a pid pointer, but failed to see the subtle race described above. So the Fixes tag picks that commit, which seems to be halfways accurate. Thanks to Frederic Weissbecker, Oleg Nesterov and Peter Zijlstra for review, feedback and suggestions and to Wongi and Jungwoo for the excellent bug report and analysis! Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Reported-by: Wongi Lee Reported-by: Jungwoo Lee Signed-off-by: Thomas Gleixner Reviewed-by: Oleg Nesterov Cc: stable@vger.kernel.org Signed-off-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 60325bf5e2c155e807270ed788c7610fd39bdbe9 Author: Thomas Gleixner Date: Wed Apr 8 13:53:56 2026 +0200 posix-timers: Expand timer_[re]arm() callbacks with a boolean return value commit 6fdb2677a594ab38eade927919bbd4d9688bfa1c upstream. In order to catch expiry times which are already in the past the timer_arm() and timer_rearm() callbacks need to be able to report back to the caller whether the timer has been queued or not. Change the function signature and let all implementations return true for now. While at it simplify posix_cpu_timer_rearm(). No functional change intended. Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Acked-by: Peter Zijlstra (Intel) Acked-by: John Stultz Link: https://patch.msgid.link/20260408114952.130222296@kernel.org Signed-off-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 5638dbfe9cf11e98a4362d2e2226eb8561cccb94 Author: Dillon Varone Date: Thu Mar 19 11:57:08 2026 -0400 drm/amd/display: Fix Color Manager (3DLUT, Shaper, Blend) commit 12f58a6caad3be54d7788b338b3f57d7c17bbef7 upstream. [WHY & HOW] The original refactor and fixes are causing regressions. Revert them for now until they can be resolved Fixes: e56e3cff2a1b ("drm/amd/display: Sync dcn42 with DC 3.2.373") Reviewed-by: Tom Chung Signed-off-by: Dillon Varone Signed-off-by: James Lin Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 570967e9c615ccea7a819cdaf4647531f71b05cb Author: Christoph Hellwig Date: Tue Jul 21 07:46:56 2026 -0400 iomap: consolidate bio submission [ Upstream commit 044472d5ee7d71f918fa3f61bd65e4933a0c006e ] Add a iomap_bio_submit_read_endio helper factored out of iomap_bio_submit_read to that all ->submit_read implementations for iomap_read_ops that use iomap_bio_read_folio_range can shared the logic. Right now that logic is mostly trivial, but already has a bug for XFS because the XFS version is too trivial: file system integrity validation needs a workqueue context and thus can't happen from the default iomap bi_end_io I/O handler. Unfortunately the iomap refactoring just before fs integrity landed moved code around here and the call go misplaced, meaning it never got called. The PI information still is verified by the block layer, but the offloading is less efficient (and the future userspace interface can't get at it). Fixes: 0b10a370529c ("iomap: support T10 protection information") Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260629121750.3392300-2-hch@lst.de Acked-by: Namjae Jeon Reviewed-by: "Darrick J. Wong" Reviewed-by: Joanne Koong Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e2f0122bd56655237b77d6a3a4673700aa4fbf08 Author: Namjae Jeon Date: Tue Jul 21 07:46:55 2026 -0400 exfat: fix implicit declaration of brelse() [ Upstream commit f0d1b2e1e02c11e29c953f22a485449e3da2a575 ] exfat_cluster_walk() calls brelse(bh) without including the header that declares the function, causing the following build error: fs/exfat/exfat_fs.h:542:9: error: implicit declaration of function ‘brelse’ [-Werror=implicit-function-declaration] Fix this by adding the missing buffer_head.h in exfat_fs.h. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8e4e884f1bef941d0940f3f321ad5aee5131a9ac Author: Namjae Jeon Date: Tue Jul 21 07:46:54 2026 -0400 exfat: add data_start_bytes and exfat_cluster_to_phys_bytes() helper [ Upstream commit 3b9450beeb961c7ddf4cccddba37fcfa6d1fcb7a ] This caches the data area start offset in bytes (data_start_bytes) and introduces a helper function exfat_cluster_to_phys_bytes() to compute the physical byte position of a given cluster. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 390f1d72a478b5e259d12565d6ad9b79027fed46 Author: Namjae Jeon Date: Tue Jul 21 07:46:53 2026 -0400 exfat: add balloc parameter to exfat_map_cluster() for iomap support [ Upstream commit 3474416bb9abafca2e79b7ff700a100b7e8bc766 ] In preparation for supporting the iomap infrastructure, we need to know whether a new cluster was allocated or not in exfat_map_cluster(). Add an optional 'bool *balloc' output parameter. When a new cluster is allocated, *balloc is set to true. Pass NULL from exfat_get_block() to preserve the existing behavior. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 69b31ef6f8530583dc2a09f782541fc881b38877 Author: Namjae Jeon Date: Tue Jul 21 07:46:52 2026 -0400 exfat: replace unsafe macros with static inline functions [ Upstream commit f07db38084dc45162d5fe2871ed72674ddc0f9ae ] The current exFAT driver relies on various macros for unit conversions between clusters, blocks, sectors, and directory entries. These macros are structurally unsafe as they lack type enforcement and are prone to potential integer overflows during bit-shift operations, especially on 64-bit architectures. Replace all arithmetic macros with static inline functions to provide strict type checking and explicit casting. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9634db561e1594c151923f4950c012161c545c93 Author: Eric Biggers Date: Sun May 31 12:17:35 2026 -0700 crypto: xilinx-trng - Remove crypto_rng interface commit 32b4d29280ed2a991dc196d5845b892acedc63b8 upstream. Implementing the crypto_rng interface has no purpose, as it isn't used in practice. It's being removed from other drivers too. Just remove it. This leaves hwrng, which is actually used. Tagging with 'Cc stable' due to the bugs that this removes: - xtrng_trng_generate() sometimes returned success even when it didn't fill in all the bytes. - It was possible for xtrng_trng_generate() and xtrng_hwrng_trng_read() to run concurrently and interfere with each other, as the locking code in xtrng_hwrng_trng_read() was broken. Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3dc8a46d08a8a060d4128e9f497060b8d03c1595 Author: Pratyush Yadav (Google) Date: Mon Jul 20 20:45:13 2026 -0400 liveupdate: validate session type before performing operation [ Upstream commit 507e3b479f9c6d85135eb5e1a77fb3fddb259ad8 ] The sessions ioctls are not applicable to all session types. PRESERVE_FD is only applicable to outgoing sessions. RETRIEVE_FD and FINISH are only valid for incoming session. Calling a incoming ioctl on an outgoing session is invalid and can cause file handlers to run into unexpected errors. For example, a user can create a (outgoing) session, preserve a memfd, and then immediately do a retrieve without doing a kexec in between. This would result in memfd's retrieve handler to run. The handlers expects to be called from a post-kexec context, and will try to do a kho_restore_vmalloc() or kho_restore_folio() to try and restore memory. KHO catches this (thanks to KHO_PAGE_MAGIC) and returns an error, but since this is considered an internal error and KHO throws out a bunch of WARN()s. Associate a type with each ioctl op and validate the type in luo_session_ioctl() before dispatching the ioctl handler to make sure the op is being called for the right session type. Fixes: 16cec0d26521 ("liveupdate: luo_session: add ioctls for file preservation") Cc: stable@vger.kernel.org Signed-off-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260519122428.2378446-1-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ddcdac47e1f2651c7be60e299f98faf981522797 Author: Mauricio Faria de Oliveira Date: Sat Jul 18 17:50:33 2026 -0400 usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() [ Upstream commit e2674dfbed8a30d57e2bc872c4bfa6c3eec918bf ] ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/ Cc: stable Reported-by: syzbot+ce1e5a1b4e086b43e56d@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d Reported-by: syzbot+306212936b13e520679d@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=306212936b13e520679d Reported-by: syzbot+457452d30bcdda75ead2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 Originally-by: Andrey Tsygunka Fixes: b72458a80c75 ("[PATCH] USB: Eagle and ADI 930 usb adsl modem driver") Assisted-by: Claude:claude-opus-4.7 # usb gadget & qemu device for testing Signed-off-by: Mauricio Faria de Oliveira Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260526-ueagle-atm_req-fw-sync-v3-1-93c01961daaf@igalia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 53430a3768b5ff6adfc319224835ef51e3bc899a Author: Mauricio Faria de Oliveira Date: Sat Jul 18 17:50:32 2026 -0400 usb: atm: ueagle-atm: remove function entry/exit debug messages [ Upstream commit 1414b2242c2e9d670c4d8b83480f13db57627ba9 ] Remove the driver-internal function entry/exit debug messages in favor of existing kernel-level function tracing mechanisms. Suggested-by: Greg Kroah-Hartman Link: https://lore.kernel.org/all/2026051657-scruffy-embark-45ea@gregkh/ Signed-off-by: Mauricio Faria de Oliveira Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260520-ueagle-atm-cleanup-v1-2-010c8bc7b214@igalia.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e2674dfbed8a ("usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10cfea5091f04c828fa23c3fbb942f5ba05fdf0e Author: Mauricio Faria de Oliveira Date: Sat Jul 18 17:50:31 2026 -0400 usb: atm: ueagle-atm: use dev_dbg() for 'device found' message [ Upstream commit 05c5075c3115010f97434c53d353d9a0d4b0e64e ] Convert dev_info() to dev_dbg(). Per 'Documentation/process/coding-style.rst': 13) Printing kernel messages ... When drivers are working properly they are quiet, so prefer to use dev_dbg/pr_debug unless something is wrong. While in there, correct the verb form and add 'with' for clarity. Suggested-by: Greg Kroah-Hartman Link: https://lore.kernel.org/all/2026051628-squatter-stature-c0e0@gregkh/ Signed-off-by: Mauricio Faria de Oliveira Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260520-ueagle-atm-cleanup-v1-1-010c8bc7b214@igalia.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e2674dfbed8a ("usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 28f19c97eab4170c08947c347fbe61707b36e184 Author: Christoph Hellwig Date: Sat Jul 18 07:51:03 2026 -0400 xfs: add newly added RTGs to the free pool in growfs [ Upstream commit ae3692c7f440c1ff577aae1a51202415ec4a794b ] When growing a zoned RT section, the newly added RTGs also need to be tagged as free in the radix tree and add to the nr_free_zones counters. Call xfs_add_free_zone to do that, otherwise using up the newly added space will wait for free zones forever. Fixes: 01b71e64bb87 ("xfs: support growfs on zoned file systems") Cc: stable@vger.kernel.org # v6.15 Reviewed-by: Damien Le Moal Reviewed-by: "Darrick J. Wong" Signed-off-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 615104cd66f878086db80956ec23a887955e8d66 Author: Christoph Hellwig Date: Sat Jul 18 07:51:02 2026 -0400 xfs: factor out a xfs_zone_mark_free helper [ Upstream commit 16fc9d358d12e6e9cc553162b4064ad58e7fa869 ] Add a helper for adding a zone to the free pool in preparation of adding another caller. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Stable-dep-of: ae3692c7f440 ("xfs: add newly added RTGs to the free pool in growfs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cfb2c6f71d61ed807c9d7a7af331d406f1f31877 Author: Namjae Jeon Date: Wed Jul 15 22:05:58 2026 -0400 ksmbd: use opener credentials for FSCTL mutations [ Upstream commit c6394bcaf254c5baf9aff43376020be5db6d3316 ] SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations. Cc: stable@vger.kernel.org Reported-by: Musaab Khan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cba4ee1092b3301ec4958f7100aa5ae2fdee8ccf Author: ChenXiaoSong Date: Wed Jul 15 22:05:57 2026 -0400 smb: move compression definitions into common/fscc.h [ Upstream commit 9d357903ec9b0da60cccc4d311f99763ba0924a2 ] These definitions will also be used by ksmbd, move them into common header file. Signed-off-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: c6394bcaf254 ("ksmbd: use opener credentials for FSCTL mutations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 98185b3025beeae92d1fe700d5db26b9ac4bf025 Author: Davide Ornaghi Date: Wed Jul 15 21:45:17 2026 -0400 ksmbd: fix path resolution in ksmbd_vfs_kern_path_create [ Upstream commit 1c8951963d8ed357f70f59e0ad4ddce2199d2016 ] The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a ".." component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves ".." out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed. Fixes: 265fd1991c1d ("ksmbd: use LOOKUP_BENEATH to prevent the out of share access") Cc: stable@vger.kernel.org Signed-off-by: Davide Ornaghi Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 733e76e74e406c1d1ddc7369420dd8a47f48bb8a Author: Siwei Zhang Date: Wed Jul 15 16:49:40 2026 -0400 Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb() [ Upstream commit 6fef032af0092ed5ccb767239a9ac1bc38c08a40 ] l2cap_sock_new_connection_cb() returned l2cap_pi(sk)->chan after release_sock(parent). Once the parent lock is dropped the newly enqueued child socket sk is reachable via the accept queue, so another task can accept and free it before the callback dereferences sk, resulting in a use-after-free. Rework the ->new_connection() op so the core, rather than the callback, owns the child channel's lifetime. The op now receives a pre-allocated new_chan and returns an errno instead of allocating and returning a channel. l2cap_new_connection() allocates the child channel and links it into the conn list via __l2cap_chan_add() before invoking the callback, so the conn-list reference keeps the channel alive once release_sock(parent) exposes the socket to other tasks. Channel configuration that was duplicated in l2cap_sock_init() and the various new_connection callbacks is consolidated into l2cap_chan_set_defaults(), which now inherits from the parent channel when one is supplied. Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c") Cc: stable@kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a2a2f68c42e0a48fe9463352888ac1df4c05eed1 Author: Pauli Virtanen Date: Wed Jul 15 16:49:39 2026 -0400 Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister [ Upstream commit 9707a015fe8f3ba8ec7c270f3b2b8efb38823d6b ] 6lowpan.c has theoretically conflicting lock orderings, which lockdep complains about: a) rtnl_lock > hdev->workqueue from 6lowpan.c:delete_netdev -> rtnl_lock -> device_del -> put_device(parent) -> hci_release_dev -> destroy_workqueue b) hdev->workqueue > l2cap_conn->lock > chan->lock > rtnl_lock from hci_rx_work -> 6lowpan.c:chan_ready_cb -> lowpan_register_netdev, ifup -> rtnl_lock Actual deadlock appears not possible, as hci_rx_work is disabled and l2cap_conn flushed already on hdev unregister. Hence, do minimal thing to make lockdep happy by breaking chain a) by holding hdev refcount until after netdev put in 6lowpan.c. Fixes the lockdep complaint: WARNING: possible circular locking dependency detected. kworker/0:1/11 is trying to acquire lock: ffff8880023b3940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x8b/0x130 but task is already holding lock: ffffffff95e4f9c0 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30 Workqueue: events delete_netdev Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 6fef032af009 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4257f45ee1fddd0558e77b62af8bb63fd87b2162 Author: Chris Mason Date: Tue Jul 14 09:40:06 2026 -0400 binder: cache secctx size before release zeroes it [ Upstream commit b34826e55aad3520ec813f1f367c11b24b29dc9f ] binder_transaction() bounds the scatter-gather buffer area with sg_buf_end_offset and subtracts the aligned LSM context size because the secctx is written at the tail of that area. The subtraction reads lsmctx.len, but that field has already been cleared by the time the line runs: security_secid_to_secctx(secid, &lsmctx) /* lsmctx.len set */ lsmctx_aligned_size = ALIGN(lsmctx.len, sizeof(u64)) extra_buffers_size += lsmctx_aligned_size ... security_release_secctx(&lsmctx) /* memset zeroes len */ ... sg_buf_end_offset = sg_buf_offset + extra_buffers_size - ALIGN(lsmctx.len, sizeof(u64)) /* ALIGN(0,8) */ security_release_secctx() does memset(cp, 0, sizeof(*cp)), so lsmctx.len reads back as 0 and the subtraction contributes nothing, leaving sg_buf_end_offset too large by the aligned secctx size on every transaction to a txn_security_ctx node. Each BINDER_TYPE_PTR object then derives buf_left = sg_buf_end_offset - sg_buf_offset as the sole upper bound on its copy, so the inflated end offset lets the copy run into the bytes that already hold the secctx. The aligned size must therefore be cached before release rather than re-read from the now-cleared field. Fix by caching it in lsmctx_aligned_size at function scope when it is first computed and subtracting lsmctx_aligned_size instead of re-reading lsmctx.len after release. Reuse the same value for the earlier buf_offset computation. Fixes: 6fba89813ccf ("lsm: ensure the correct LSM context releaser") Cc: stable Assisted-by: kres:claude-opus-4-8 Signed-off-by: Chris Mason Reviewed-by: Alice Ryhl Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260603174506.1957278-1-clm@meta.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f54f2310de0a91099e2ac7e2aed312df6eaa1d8 Author: Jisheng Zhang Date: Tue Jul 14 09:40:05 2026 -0400 binder: Use LIST_HEAD() to initialize on stack list head [ Upstream commit 91f818b184b44b105b1c92859ea8d2d6f47912a9 ] Use LIST_HEAD to initialize on stack list head. No intentional functional impact. Change generated with below coccinelle script: @@ identifier name; @@ - struct list_head name; + LIST_HEAD(name); ... when != name - INIT_LIST_HEAD(&name); Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20260519055623.13142-1-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: b34826e55aad ("binder: cache secctx size before release zeroes it") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit da9e3be9cf31d7138d23e9e2f7ba1c102ef09f07 Author: Cássio Gabriel Date: Mon Jul 13 23:32:56 2026 -0400 ALSA: hda/tas2781: Cancel async firmware request at unbind [ Upstream commit 5367e2ad14f0ae9350a7aaf2e77c87de39a43ae9 ] TAS2781 HDA I2C and SPI queue RCA firmware loading from component bind with request_firmware_nowait(). The firmware loader keeps the callback module pinned and holds a device reference, but the callback still uses driver-private HDA state. Component unbind removes controls and DSP state immediately. Later device removal tears down the TAS2781 private data, including codec_lock. If the async firmware callback runs after unbind has started, it can operate on state that is being torn down. Cancel or synchronize the async firmware request before removing controls and DSP state. A queued callback is cancelled, and an already-running callback is allowed to finish before unbind continues. Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") Fixes: bb5f86ea50ff ("ALSA: hda/tas2781: Add tas2781 hda SPI driver") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Takashi Iwai Acked-by: Danilo Krummrich Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260505-alsa-hda-tas2781-fw-callback-teardown-v4-2-e7c4bf930dc8@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd992747d717c2152fef77ec6256b8a1d8b75d68 Author: Cássio Gabriel Date: Mon Jul 13 23:32:55 2026 -0400 firmware_loader: Add cancel helper for async requests [ Upstream commit b9bdd68b8b979c7e9de58b2e7d21e1d7d932c755 ] request_firmware_nowait() keeps the callback module pinned and holds a device reference until the firmware work completes. Callers still have no way to cancel or synchronize the queued callback before tearing down their driver-private state. Track scheduled async firmware work in an internal list and add request_firmware_nowait_cancel(). The helper cancels work matching the device, callback context and callback function. It cancels work that has not started yet and waits for an already-running callback to return. If the request has already completed, it is a no-op. Keep the existing request_firmware_nowait() lifetime model manual. A devres-managed variant can be layered on top separately if needed. Signed-off-by: Cássio Gabriel Reviewed-by: Takashi Iwai Acked-by: Danilo Krummrich Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260505-alsa-hda-tas2781-fw-callback-teardown-v4-1-e7c4bf930dc8@gmail.com Stable-dep-of: 5367e2ad14f0 ("ALSA: hda/tas2781: Cancel async firmware request at unbind") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ac1328962db1b6297ce880e8d98cefcd005fbba4 Author: Geoffrey D. Bennett Date: Mon Jul 13 21:16:23 2026 -0400 ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417 [ Upstream commit 3ca15754b561483aa7a1bce51677d6389f8ff5bb ] Firmware 2417 for the Scarlett 4th Gen 2i2 moved the direct monitor gain parameters, so add a second config_set with the shifted offset and select it for firmware versions >= 2417. Fixes: 4e809a299677 ("ALSA: scarlett2: Add support for Solo, 2i2, and 4i4 Gen 4") Cc: stable@vger.kernel.org # ALSA: scarlett2: Allow selecting config_set by firmware version Cc: stable@vger.kernel.org # ALSA: scarlett2: Fold min_firmware_version into config_sets Cc: stable@vger.kernel.org Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/ad0fc5a131e76eb656a24e0e198382f7134068fe.1777151532.git.g@b4.vu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 53e3dcfa74b350062742b46a71c3524bf0864c68 Author: Geoffrey D. Bennett Date: Mon Jul 13 21:16:22 2026 -0400 ALSA: scarlett2: Allow selecting config_set by firmware version [ Upstream commit 732a6397a526c025cd29c3c9309b0db6a2c08837 ] The Scarlett 2i2 Gen 4 firmware 2417 moved the direct monitor gain parameters, so we now need to allow each device to list multiple scarlett2_config_set entries, one per applicable firmware version range, and pick the matching one at probe time. No functional change yet: each device gets a single config_sets entry whose from_firmware_version matches the existing min_firmware_version (0 where none was set). This both prepares for selection and lets a follow-up commit remove the now-redundant min_firmware_version field. scarlett2_count_io() depends on the resolved config_set so it moves out of scarlett2_init_private() into snd_scarlett2_controls_create() after the firmware version has been read. Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/ae1695b4c4825f365b4c86b22174035f742807e3.1777151532.git.g@b4.vu Stable-dep-of: 3ca15754b561 ("ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b80d602496863df573863165e8d6c92ce2f8279a Author: Zhang Lixu Date: Mon Jul 13 13:53:24 2026 -0400 iio: hid-sensor-rotation: Fix stale or zero output when reading raw values [ Upstream commit 3ce8d099e0afc5a7da75a2007a67f67c4f5a4af1 ] When reading the raw quaternion attribute (in_rot_quaternion_raw), the driver currently returns either all zeros (if the sensor was never enabled) or stale data (if the sensor was previously enabled) because it reads from the internal buffer without explicitly requesting a new sample from the sensor. To fix this, power up the sensor, call sensor_hub_input_attr_read_values() to issue a synchronous GET_REPORT and receive the full quaternion data directly into a local buffer, then decode the four components. Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support") Signed-off-by: Zhang Lixu Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c0dbfecd859fd02fe9008f33a83146102ccd9ba Author: Keshav Verma Date: Fri Jul 3 14:24:22 2026 -0400 f2fs: fix listxattr handling of corrupted xattr entries [ Upstream commit 5ef5bc304f23c3fe255d4936472378dcb74d0e94 ] Validate the xattr entry before reading its fields in f2fs_listxattr(). Return -EFSCORRUPTED when the entry is outside the valid xattr storage area instead of returning a successful partial result. Fixes: 688078e7f36c ("f2fs: fix to avoid memory leakage in f2fs_listxattr") Cc: stable@kernel.org Reviewed-by: Chao Yu Signed-off-by: Keshav Verma Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa807064473abd6f2cafe419fb77ea402d3e3104 Author: Chao Yu Date: Fri Jul 3 10:26:30 2026 -0400 f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() [ Upstream commit 8b4468ec023d0d1b4669dfb867588997cc03a06b ] When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker GC trehad Truncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work - truncate_inode_pages_range - __filemap_get_folio(, FGP_LOCK) --- lock folio - truncate_inode_partial_folio - folio_wait_writeback --- wait on writeback being cleared - do_garbage_collect - move_data_page - f2fs_get_lock_data_folio - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi); Cc: stable@kernel.org Fixes: 351df4b20115 ("f2fs: add segment operations") Cc: Ruipeng Qi Reported: Sandeep Dhavale Signed-off-by: Chao Yu Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf8b5937b7b258927ccca267995e13e76a07b38e Author: Ruipeng Qi Date: Fri Jul 3 10:26:29 2026 -0400 f2fs: fix potential deadlock in f2fs_balance_fs() [ Upstream commit dd3114870771562036fdcf5abe813956f36d224d ] When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:2769849 tgid:2769849 ppid:736 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 wb_wait_for_completion+0xb0/0xe8 sync_inodes_sb+0xc8/0x2b0 sync_inodes_one_sb+0x24/0x38 iterate_supers+0xa8/0x138 ksys_sync+0x54/0xc8 __arm64_sys_sync+0x18/0x30 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 The root cause is a potential deadlock between the following tasks: kworker/u8:11 Thread A - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback(X) - f2fs_outplace_write_data - bio_add_folio(X) - folio_unlock(X) - truncate_inode_pages_range - __filemap_get_folio(X, FGP_LOCK) - truncate_inode_partial_folio(X) - folio_wait_writeback(X) - f2fs_balance_fs - f2fs_gc - do_garbage_collect - move_data_page - f2fs_get_lock_data_page - __filemap_get_folio(X, FGP_LOCK) Both threads try to access folio X. Thread A holds the lock but waits for writeback, while kworker waits for the lock. This causes a deadlock. Other threads also enter D state, waiting for locks such as gc_lock and writepages. OPU/IPU DATA folio are all affected by this issue. To avoid such potential deadlocks, always commit these cached folios before triggering f2fs_gc() in f2fs_balance_fs(). Suggested-by: Chao Yu Reviewed-by: Chao Yu Signed-off-by: Ruipeng Qi Signed-off-by: Jaegeuk Kim Stable-dep-of: 8b4468ec023d ("f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c81e2af41de6a159837c7129a4fc444ac6e48046 Author: Bartosz Golaszewski Date: Thu Jul 2 10:29:56 2026 -0400 device property: initialize the remaining fields of fwnode_handle in fwnode_init() [ Upstream commit 7eba000621fff223dd7bab484d48918c7c77a307 ] If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. Cc: stable@vger.kernel.org Fixes: 01bb86b380a3 ("driver core: Add fwnode_init()") Reviewed-by: Sakari Ailus Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260511074927.9473-1-bartosz.golaszewski@oss.qualcomm.com [ Fix typo in commit message. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db20589d7b248211f63f4a7f642a49c0832b13ae Author: Zenghui Yu Date: Mon Jun 29 07:44:31 2026 -0700 samples/damon/mtier: fail early if address range parameters are invalid commit 7746d72c64054976887928d64d2caf25c5a6dcc0 upstream. The comment on top of `struct damon_region` clearly says that For any use case, @ar should be non-zero positive size. which is now verified in damon_verify_new_region() if the kernel is built with DAMON_DEBUG_SANITY. The WARN_ONCE() can be triggered if the mtier sample module is enabled before node{0,1}_{start,end}_addr have been properly initialized, which is obviously not good. ------------[ cut here ]------------ start 0 >= end 0 WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468 Call trace: damon_new_region+0xf4/0x118 (P) damon_set_regions+0xfc/0x3c0 damon_sample_mtier_build_ctx+0xe8/0x3a8 damon_sample_mtier_start+0x1c/0x90 damon_sample_mtier_enable_store+0x98/0xb0 param_attr_store+0xb4/0x128 module_attr_store+0x2c/0x50 sysfs_kf_write+0x58/0x90 kernfs_fop_write_iter+0x16c/0x238 vfs_write+0x2c0/0x370 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 invoke_syscall+0xa8/0x118 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x54/0x370 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]--- Note that the same issue can happen if detect_node_addresses is true, and node 0 or 1 is memoryless. Fix it together by checking the validity of parameters right before damon_new_region() and fail early if they're invalid. Link: https://lore.kernel.org/20260629144432.133962-1-sj@kernel.org Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: Zenghui Yu Signed-off-by: SJ Park Reviewed-by: SJ Park Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 810c9ae71dadc5887c6b37308fabad5f6f3bd870 Author: SJ Park Date: Wed May 20 08:03:10 2026 -0700 mm/damon/core: trace esz at first setup commit 7e6cc35f5283eab81a14231a64ecd640b690c48c upstream. DAMON traces effective size quota from the second update, only if a change has been made by the update. Tracing only changed updates was an intentional decision to avoid unnecessary same value tracing. Always skipping the first value is just an unintended mistake. The mistake makes the tracepoint based investigation incomplete, because the first effective size quota is never traced. It is not a big issue when the 'consist' quota tuner is used, because it keeps changing the quota in the usual setup. However, when the 'temporal' tuner is used, the quota value is not changed before the goal achievement status is completely changed. For example, if the DAMOS scheme is started with an under-achieved goal, the quota is set to the maximum value, and kept the same value until the goal is achieved. Because DAMON skips the first value, the user cannot know what effective quota the current scheme is using. Only after the goal is achieved, the effective quota is changed to zero, and traced. Unconditionally trace the initial quota value to fix this problem. Note that the 'temporal' quota tuner was introduced by commit af738a6a00c1 ("mm/damon/core: introduce DAMOS_QUOTA_GOAL_TUNER_TEMPORAL"), which was added to 7.1-rc1. But even with the 'consist' quota tuner, the tracing is unintentionally incomplete. Hence this commit marks the introduction of the trace event as the broken commit. Link: https://lore.kernel.org/20260520150311.80925-1-sj@kernel.org Fixes: a86d695193bf ("mm/damon: add trace event for effective size quota") Signed-off-by: SeongJae Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 314bd592085c0720ef519f6edbc5f41440ff78d4 Author: Sun Jian Date: Tue Jul 14 02:38:45 2026 -0700 bpf: Reject negative const offsets for buffer pointers commit fd4cfa8c8f9a17cdec0539334d28754bc1d8a5d9 upstream. The verifier rejects variable offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF accesses, but it currently accepts a constant negative offset produced by pointer arithmetic. Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") moved constant pointer offsets from reg->off to reg->var_off. However, __check_buffer_access() continued to check only the instruction offset. An access with reg->var_off equal to -8 and an instruction offset of zero therefore passes verification. For writable raw tracepoints, the access end is also calculated from the unsigned reg->var_off.value. An eight-byte access starting at -8 wraps the calculated end to zero, allowing the program to load and attach without increasing max_tp_access. After ensuring that reg->var_off is constant, calculate the effective access start using signed arithmetic and reject it when it is negative. Use the validated start to calculate the access end for both PTR_TO_TP_BUFFER and PTR_TO_BUF. Fixes: 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") Signed-off-by: Sun Jian Acked-by: Shung-Hsi Yu Cc: stable@vger.kernel.org # 5.2.0 Link: https://patch.msgid.link/20260714093846.18159-2-sun.jian.kdev@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Greg Kroah-Hartman commit a419421281fb4b61ab4c277b7e97fd04d3be9b94 Author: Luke Wang Date: Wed Jul 15 15:18:18 2026 +0800 mmc: sdhci-esdhc-imx: fix resume error handling commit e27c946b589c53520409a0956b33d52ef7a0898f upstream. Check pm_runtime_force_resume() return value in resume. If it fails (clock enable failure), return immediately since accessing hardware registers on an unclocked device would cause a kernel panic. The early return intentionally skips enable_irq() and sdhci_disable_irq_wakeups() because the IRQ handler reads SDHCI_INT_STATUS, which would also fault without clocks. The PM runtime usage counter leak only affects this already-broken device instance and is an acceptable tradeoff to preserve system stability. Remove the return value check for mmc_gpio_set_cd_wake(host->mmc, false) since disable_irq_wake() called internally always returns 0. Also return 0 explicitly on the success path instead of propagating stale return values. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Reviewed-by: Frank Li Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 89b63cd133fe96cdf2c4eb73cf1d1a8a92a26f96 Author: Luke Wang Date: Wed Jul 15 15:18:17 2026 +0800 mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend commit 6aa00a43bbd3d994558a55586351757cebbff236 upstream. Make pinctrl_pm_select_sleep_state() and mmc_gpio_set_cd_wake() failures non-fatal in the suspend path. These failures only mean slightly higher power consumption or missing CD wakeup capability, but should not block system suspend. Also change the function to always return 0 on the success path instead of propagating non-fatal warning return values. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6355749aebf6c78081f7096a52edcd28d2aa0fab Author: Luke Wang Date: Wed Jul 15 15:18:16 2026 +0800 mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend commit 8da5930144712412d85e7f868693d96ec5c2018c upstream. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() to simplify error handling. pm_runtime_resume_and_get() automatically drops the usage counter on failure, avoiding the need for a separate pm_runtime_put_noidle() call. If it fails, the device is unclocked and accessing hardware registers would cause a kernel panic, so return the error immediately. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 9bf4ee05a1109d889de9151ee78bd80293923f70 Author: Luke Wang Date: Wed Jul 15 15:18:15 2026 +0800 mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt commit 9d87eaf985cef9581b6ed99b461b38e8cd666480 upstream. When using WIFI out-of-band wakeup, an "irq xxx: nobody cared" warning occurs. This happens because the usdhc interrupt is not disabled during system suspend when device_may_wakeup() returns false. The sequence of events leading to this issue: 1. System enters suspend without disabling usdhc interrupt (because device_may_wakeup() returns false for usdhc device) 2. WIFI out-of-band wakeup triggers system resume via GPIO interrupt 3. WIFI sends a Card interrupt before usdhc has fully resumed 4. usdhc is still in runtime suspend state and cannot handle the interrupt properly 5. The unhandled interrupt triggers "nobody cared" warning Fix this by unconditionally disabling the usdhc interrupt during suspend and re-enabling it during resume, regardless of the wakeup capability. This ensures no interrupts are processed during the suspend/resume transition. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Reviewed-by: Haibo Chen Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bb72b2398c05fd0a4ebf13f49c7d599d7023d484 Author: Luke Wang Date: Wed Jul 15 15:18:13 2026 +0800 mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restore commit 5adc14cd4b905629d5b9163b3a416dcab24c7ce2 upstream. esdhc_change_pinstate() checks for pins_100mhz and pins_200mhz at the top of the function and returns -EINVAL if either is not defined. This prevents the default case from ever being reached, which means devices with a sleep pinctrl state but without high-speed pin states (100mhz/ 200mhz) can never restore their default pin configuration. Move the IS_ERR checks for pins_100mhz and pins_200mhz into their respective switch cases. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Reviewed-by: Frank Li Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 24300decd8bd6cdbc32dc39cb78a929c713e485c Author: Luke Wang Date: Wed Jul 15 15:18:12 2026 +0800 mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume commit 2439becd91bad6883b135044f85f83a0538b96a6 upstream. sdhci_esdhc_imx_hwinit() unconditionally clears ESDHC_DLL_CTRL by writing zero. For SDIO devices that keep power during system suspend and operate in DDR mode, the card remains in DDR timing while the host DLL override configuration is lost. Extract the DLL override setup from esdhc_set_uhs_signaling() into a helper esdhc_set_dll_override(), and call it on the resume path when the card kept power and is using a DDR timing mode. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Reviewed-by: Frank Li Reviewed-by: Haibo Chen Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 48188934d5d2b4aa806f462859b1fc4d7d2ae0f4 Author: Luke Wang Date: Wed Jul 15 15:18:11 2026 +0800 mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check for tuning save/restore commit 899160e2774d9952e9f2770b38f701ff1906c0b2 upstream. The tuning save/restore during system PM is conditioned on mmc_card_wake_sdio_irq(), but this check is unrelated to whether tuning values need to be preserved. The actual requirement is that the card keeps power during suspend and the controller is a uSDHC. SDIO devices using out-of-band GPIO wakeup maintain power during suspend but do not set the SDIO IRQ wake flag. In this case the tuning delay values are not saved/restored. Remove the unnecessary mmc_card_wake_sdio_irq() condition from both the suspend save and resume restore paths. Fixes: c63d25cdc59a ("mmc: sdhci-esdhc-imx: Save tuning value when card stays powered in suspend") Acked-by: Adrian Hunter Reviewed-by: Frank Li Reviewed-by: Haibo Chen Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 657e0acce5b8d397011b7045f1c4d6e86b66a415 Author: Sergey Shtylyov Date: Mon Jun 1 17:49:01 2026 +0300 mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe() method commit 521f39ca93cc43ce1b3eae8d44201f8f55dd9151 upstream. In the driver's probe() method, clk_disable_unprepare() for the bus clock is called on the error path even if the prior clk_prepare_enable() call has failed (and the same thing happens in the remove() method as well) -- that would cause the prepare/enable counter imbalance. Also, the same problem can happen in the driver's suspend() method; note that the resume() method does check the clk_prepare_enable()'s result -- let's be consistent and do that in probe() method as well. BTW, I don't know for sure what does the bus clock control -- if it affects the register accesses, the driver will likely cause (e.g. on ARM) a kernel oops if it fails to prepare/enable the bus clock in the probe() method... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: e438cf49b305 ("mmc: sdhci-of-dwcmshc: add SDHCI OF Synopsys DWC MSHC driver") Fixes: bccce2ec7790 ("mmc: sdhci-of-dwcmshc: add suspend/resume support") Signed-off-by: Sergey Shtylyov Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f59d0244d90b0abd0467a44a3e03155623b81125 Author: Lad Prabhakar Date: Tue Jun 2 21:13:44 2026 +0100 mmc: mmc_test: Fix __counted_by handling after kzalloc_flex() conversion commit c35fac6481a1dbb2d114dd337b54a40799437546 upstream. Fix logic issues introduced by the kzalloc_flex() conversion in mmc_test_alloc_mem() due to interaction with the __counted_by annotation on the flexible array. Bounds-checking sanitizers rely on the counter field reflecting the allocated array size before any array access occurs. However, use mem->cnt both as the allocation size and as the runtime insertion index, causing incorrect indexing and potentially invalid bounds tracking. Initialize mem->cnt to the maximum allocated number of segments immediately after kzalloc_flex(), then use a separate local index variable to track successfully allocated entries. Update mem->cnt to the actual number of initialized elements before returning or entering the cleanup path. Also rewrite mmc_test_free_mem() to use a forward for-loop, improving readability and ensuring only initialized entries are freed. Fixes: c3126dccfd7b ("mmc: mmc_test: use kzalloc_flex") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0e93010b52bba0b55a05597f5d3a24ce07770295 Author: Ao Sun Date: Mon Jul 6 11:43:00 2026 +0000 mmc: block: fix RPMB device unregister ordering commit 86152fef52cac15cd662ed3bfc7604fbfef378f0 upstream. Since commit 7852028a35f0 ("mmc: block: register RPMB partition with the RPMB subsystem"), each mmc RPMB partition is represented by two device objects: - the mmc-owned device (`rpmb->dev`, backing the legacy /dev/mmcblkXrpmb char device) and - the rpmb-core device (`rdev`, backing /dev/rpmbN). The child RPMB device holds a reference to its parent, so the parent's release callback cannot be invoked if the child device is still registered. Remove rpmb_dev_unregister() from the parent release handler and unregister the child RPMB device in the remove path before tearing down the parent device. Also delete the extra blank line between mmc_blk_remove_rpmb_part() and {. Fixes: 7852028a35f0 ("mmc: block: register RPMB partition with the RPMB subsystem") Cc: stable@vger.kernel.org Signed-off-by: Jiazi Li Signed-off-by: Ao Sun Reviewed-by: Avri Altman Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cb2031f8b226efbd13735c07b075e5f14ec11f6d Author: Pengpeng Hou Date: Fri Jul 3 15:39:43 2026 +0800 mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout commit 17a8ce84964f243c8f89dc7353ac7e8d3137bc74 upstream. lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned. Fixes: 2944a44da09e ("mtd: add LPC32xx SLC NAND driver") Cc: stable@vger.kernel.org Reviewed-by: Vladimir Zapolskiy Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 791fc00d116e6f7076c2bb95c29d63a56aad63de Author: Pengpeng Hou Date: Fri Jul 3 15:37:59 2026 +0800 mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout commit dbf590b662695b16fbf5917ef129697be4410ea9 upstream. lpc32xx_xmit_dma() starts a DMA transfer and waits up to one second for its completion, but it ignores the wait result and returns success after unmapping the buffer. A timed out read can therefore return success with incomplete data, and a timed out write can continue the NAND operation without proof that the DMA payload reached the controller. Terminate the DMA channel on timeout, unmap the scatterlist through the existing cleanup path, and return -ETIMEDOUT to the NAND read/write callers. Initialize the shared cleanup-path result before using it for dmaengine_prep_slave_sg() failures. Fixes: 70f7cb78ec53 ("mtd: add LPC32xx MLC NAND driver") Cc: stable@vger.kernel.org Reviewed-by: Vladimir Zapolskiy Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 1773c6e292b044cecf252e8269f0bbfc94578e98 Author: Pengpeng Hou Date: Fri Jul 3 15:42:33 2026 +0800 mtd: rawnand: fsl_ifc: return errors for failed page reads commit f9a13e05a327080c3a1c8165adf9e678fb68fef2 upstream. fsl_ifc_run_command() logs controller timeout and other non-OPC completion states in ctrl->nand_stat. fsl_ifc_read_page() then only increments the ECC failure counter for non-OPC status and still returns max_bitflips, which can be zero. Return -ETIMEDOUT when the command did not complete at all and -EIO for other non-OPC read completions so the NAND core does not treat a failed page read as a clean page. Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit c2e1d33929565fa14c48d8a5a45edc3ebfc941b2 Author: Runyu Xiao Date: Wed Jun 17 23:23:19 2026 +0800 mmc: vub300: defer reset until cmd_mutex is unlocked commit ee5fb641c4ccac8406c668d3e947eb20ce44f233 upstream. vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock. Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 09e044192a42f716215fbd1a100ee87fa57426aa Author: Pengpeng Hou Date: Fri Jul 3 15:40:52 2026 +0800 mtd: mchp23k256: use SPI match data for chip caps commit d322e40f4edf92bf0ca329e5aa4ae1c0316feb38 upstream. The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches. Fixes: 4379075a870b ("mtd: mchp23k256: Add support for mchp23lcv1024") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 9fc23fc52fc90d7abf328d9e4e45443d6997b8ad Author: Pengpeng Hou Date: Fri Jul 3 15:43:50 2026 +0800 mtd: onenand: samsung: report DMA completion timeouts commit d03a19bd6c7f86b99ca8fb61a6ec2345cee1d9d6 upstream. The S5PC110 OneNAND DMA helpers have bounded waits for transfer completion. The polling helper falls out of its timeout loop and returns success, and the IRQ helper ignores wait_for_completion_timeout(). Return -ETIMEDOUT when the DMA transfer-done bit or completion does not arrive before the timeout so callers can treat the buffer transfer as failed. Fixes: e23abf4b7743 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 0e65079d28e5c461b6813ea5821be4dfff24ff63 Author: Xu Rao Date: Fri Jun 26 10:13:38 2026 +0800 mtd: virt-concat: free duplicate generated name commit caa0ecbeff4f7fbf70f22bd8ca598918bffb1b78 upstream. Every MTD registration runs mtd_virt_concat_create_join(). Once a virtual concat has already been registered, the function builds the same name again and takes the equal-name branch. That branch skips to the next item without freeing the newly allocated string. Free the temporary name before continuing. Fixes: 43db6366fc2d ("mtd: Add driver for concatenating devices") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 6126e12bf8c87badeab41a164c9689ac88e5c160 Author: Rafael Beims Date: Fri Jun 12 09:25:46 2026 -0300 wifi: mwifiex: fix permanently busy scans after multiple roam iterations commit d78a407bad6f500884a8606aea1a5a9207be4030 upstream. In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running "test 1)" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Rafael Beims Reviewed-by: Jeff Chen Link: https://patch.msgid.link/20260612122547.1586872-2-rafael@beims.me Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 625fc704b19cb48d7d269ad54ffffb4d3bf9c7ed Author: Zhao Li Date: Fri Jun 12 00:19:45 2026 +0800 wifi: mac80211: validate extension-frame layout before RX commit 57d503ce32eccfa7650065ca4c560f7e29a2e676 upstream. Extension frames only have the extension header at the regular 802.11 header offset. The generic RX path can still reach helpers and interface dispatch code that read regular header address fields before unsupported extension subtypes are dropped. mac80211 currently only handles S1G beacon extension frames. Drop other extension subtypes before they can reach regular-header RX processing. For S1G beacons, linearize the SKB with the management-frame path and require the fixed S1G beacon header, including optional fixed fields indicated by frame control, before generic RX dispatch. Route S1G beacons through the station/default-link RX path without regular-header station lookup. Avoid regular-header address reads in the mac80211 RX paths that process S1G extension beacons, including accept-frame, duplicate-detection, address-copy, and MLO address-translation paths. Also make ieee80211_get_bssid() length-safe before returning the S1G source-address pointer. Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons") Cc: stable@vger.kernel.org Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260611161943.91069-5-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 179d9be632d82aa654bae50fd3efc556822458c1 Author: Zhiling Zou Date: Sat Jun 27 00:58:30 2026 +0800 wifi: mac80211: free ack status frame on TX header build failure commit 2c51457d930f723e5f2903af90f5847f7df53f42 upstream. ieee80211_build_hdr() stores an ACK status frame before it has finished all validation and header construction. If a later error path is taken, the transmit skb is freed but the stored ACK status frame remains in local->ack_status_frames. This can happen for control port frames when the requested MLO link ID does not match the link selected for a non-MLO station. Repeated failures can fill the ACK status IDR and leave pending ACK frames until hardware teardown. Remove any stored ACK status frame before returning an error after it has been inserted into the IDR. Fixes: a729cff8ad51 ("mac80211: implement wifi TX status") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Link: https://patch.msgid.link/9de0423da840e92084915b8f92e66a421245c4b8.1782462409.git.roxy520tt@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2b1589fd9a076727a73bfb39e96622a76415ad32 Author: Zhao Li Date: Fri Jun 12 01:35:07 2026 +0800 wifi: ieee80211: validate MLE common info length commit 293baeae9b2434a3e432629d7720b5603db2d77e upstream. ieee80211_mle_common_size() uses the first common-info octet as the common information length for all known MLE types. However, ieee80211_mle_size_ok() only validates that octet for Basic, Probe Request, and TDLS MLEs. Reconfiguration MLEs also skipped the length octet when calculating the minimum common size, and Priority Access MLEs skipped validation of the advertised common information length. Account for the Reconfiguration common-info length octet and validate the advertised common information length for all known MLE types. Keep unknown-type handling unchanged. Fixes: 0f48b8b88aa9 ("wifi: ieee80211: add definitions for multi-link element") Cc: stable@vger.kernel.org Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260611173506.36838-2-enderaoelyther@gmail.com [remove now misleading comment] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3b0505e43da8fb5b2a7994c3c3604e5a74692154 Author: Haofeng Li Date: Wed Jul 1 17:33:27 2026 +0800 wifi: cfg80211: validate EHT MLE before MLD ID read commit 74e27cd1d98b546fdb276008a83708d062339661 upstream. cfg80211_gen_new_ie() copies ML probe response elements from the parent frame when the parent EHT multi-link element has an MLD ID matching the nontransmitted BSSID index. The code only checked that the extension element had more than one byte before calling ieee80211_mle_get_mld_id(). That helper assumes a BASIC MLE with enough common info and documents that callers must first use ieee80211_mle_type_ok(). Attack chain: malicious AP sends a short EHT MLE in an MBSSID beacon. cfg80211_inform_bss_frame_data() stores the copied IE buffer. cfg80211_parse_mbssid_data() builds the nontransmitted BSS IE. cfg80211_gen_new_ie() sees the EHT MLE in the parent frame. ieee80211_mle_get_mld_id() then reads past the IE boundary. Validate the MLE type and size before reading the MLD ID. This matches the contract required by the MLE helper and rejects the short element before any internal MLE fields are accessed. Cc: stable@vger.kernel.org Fixes: 61dcfa8c2a8f ("wifi: cfg80211: copy multi-link element from the multi-link probe request's frame body to the generated elements") Signed-off-by: Haofeng Li Link: https://patch.msgid.link/20260701093327.2680709-1-lihaofeng@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d5c234774a82f27b594f70c15fc45ce3648e4295 Author: Ethan Nelson-Moore Date: Mon Jun 15 16:37:26 2026 -0700 powerpc/uaccess: correct check for CONFIG_PPC_E500 in mask_user_address() commit d610d3ab18197d87618da11ec5fe8b3cebf32208 upstream. mask_user_address() incorrectly checks for CONFIG_E500 instead of CONFIG_PPC_E500, causing mask_user_address_isel() to not be used on E500 hardware. Fix the check to use the correct name. Fixes: 861574d51bbd ("powerpc/uaccess: Implement masked user access") Cc: stable@vger.kernel.org # 7.0+ Signed-off-by: Ethan Nelson-Moore Fixes: 861574d51bbd ("powerpc/uaccess: Implement masked user access") Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260615233729.29386-1-enelsonmoore@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4efa313b15925bdd864784865d6585174979294b Author: Junrui Luo Date: Mon Jun 1 15:50:00 2026 +0800 powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() commit 47b87f469a35b5ffc81c16eee6b13a9b6c8d55c6 upstream. spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault(). Fixes: a352894d0705 ("spufs: use new vm_ops->access to allow local state access from gdb") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/SYBPR01MB7881EE775E8B51C09F5A29E7AF152@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit d826d3e04c5bd9d284ba29f330246a317a8a7023 Author: Zhao Dongdong Date: Wed Jun 17 11:16:27 2026 +0800 reset: sunxi: fix memory region leak on ioremap failure commit 1a8c89f8c112c75e84ff9a140f969e372aed0c9a upstream. In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure. Fixes: 8f1ae77f4666 ("reset: Add Allwinner SoCs Reset Controller Driver") Cc: stable@vger.kernel.org Signed-off-by: Zhao Dongdong Reviewed-by: Philipp Zabel Acked-by: Jernej Skrabec Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 68176d47421f255734af492c879633047e530cef Author: Robby Cai Date: Fri Jun 19 15:31:15 2026 +0800 reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ commit 71827776667f4e4677a4fa806bcfb24d4b8dd9d7 upstream. On i.MX8MQ, the MIPI CSI reset lines are active-low and not self-clearing. Writing '0' asserts reset and it remains asserted until explicitly deasserted by software. This driver previously treated the MIPI CSI reset signals as active-high, which led to incorrect reset assert/deassert sequencing. This issue was exposed by commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly release reset"). Fix this by reflecting the correct reset polarity and ensuring proper reset handling. Fixes: c979dbf59987 ("reset: imx7: Add support for i.MX8MQ IP block variant") Cc: stable@vger.kernel.org # 6d79bb8fd2aa: media: imx8mq-mipi-csi2: Explicitly release reset Reviewed-by: Philipp Zabel Signed-off-by: Robby Cai Reviewed-by: Guoniu Zhou Reviewed-by: Frank Li Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit ad1e14710b360bda087ebf9fb82460eb5ef775de Author: Florian Westphal Date: Wed Jul 8 16:21:30 2026 +0200 ipvs: reload ip header after head reallocation commit a2f57827bf7c695b8c72dc4511cae8e86582369d upstream. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head. Fixes: 8d8e20e2d7bb ("ipvs: Decrement ttl") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 905d7a363ade96a19f214815361e11981142c547 Author: Julian Anastasov Date: Wed Jul 8 21:03:15 2026 +0300 ipvs: fix more places with wrong ipv6 transport offsets commit b3fe4cbd583895987935a9bdad01c8f9d3a02310 upstream. Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers. Fixes: d12e12299a69 ("ipvs: add ipv6 support to ftp") Fixes: 2a3b791e6e11 ("IPVS: Add/adjust Netfilter hook functions and helpers for v6") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260706101624.69471-1-zhaoyz24%40mails.tsinghua.edu.cn Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 47f0c7d856c67c9935546d2644f18c0d0131b449 Author: Maoyi Xie Date: Thu Jul 2 16:27:45 2026 +0800 memstick: ms_block: reject a card that reports too many blocks commit 718178f524b98bc920d74bc771aed823c8b81425 upstream. msb_ftl_initialize() computes the zone count from the card block count with no bound: msb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; ... for (i = 0; i < msb->zone_count; i++) msb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 492cf7778a5516ea270582878c0d922c74e6af72 Author: James Raphael Tiovalen Date: Sun Jul 5 19:36:29 2026 +0800 macsec: fix promiscuity refcount leak in macsec_dev_open() commit 7410d11460eb90d6c9281162ccc6a128534d897d upstream. When a MACsec interface with IFF_PROMISC set is brought up on top of a device that has hardware offload enabled, macsec_dev_open() first calls dev_set_promiscuity(real_dev, 1) and then propagates the open to the offload device. If that propagation fails, the error path jumps to the clear_allmulti label, which only reverts allmulti and the unicast address. The promiscuity taken on the lower device is never dropped, so real_dev is left permanently stuck in promiscuous mode. Its promiscuity count can no longer be balanced from software. Add a clear_promisc label that drops the promiscuity reference and route the two offload failure paths to it. The dev_set_promiscuity() failure itself still jumps to clear_allmulti, since on that failure the count was not incremented. Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure") Cc: stable@vger.kernel.org Signed-off-by: James Raphael Tiovalen Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260705113629.187490-1-jamestiotio@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3cc37687227b5be2c7c753371ed4b71cc5ece1cf Author: Xuanqiang Luo Date: Sun Jul 12 21:03:43 2026 +0800 llc: fix SAP refcount leak when creating incoming sockets commit 2c72eb6286347d05a885412fb076993bd5286b53 upstream. llc_sap_add_socket() takes a SAP reference for each socket added to a SAP, and llc_sap_remove_socket() releases it. llc_create_incoming_sock() takes an additional SAP reference after adding the child socket. This extra reference was balanced by an explicit llc_sap_put() in llc_ui_release() until commit 3100aa9d74db ("llc: fix SAP reference counting w.r.t. socket handling") removed that put. The corresponding hold in the accept path was left behind. When such a child socket is removed, only the reference taken by llc_sap_add_socket() is released. The extra reference keeps the SAP alive after its last socket is removed. Remove the obsolete hold. Fixes: 3100aa9d74db ("llc: fix SAP reference counting w.r.t. socket handling") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260712130343.518797-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 5c1e8f56d84cc416aa36fff5755f8e4947c76574 Author: Eric Biggers Date: Wed Jul 8 22:29:54 2026 -0400 crypto: aes - Fix conditions for selecting MAC dependencies commit e073f1238ecaea366f53e98724c40b31856da56a upstream. Starting in commit 7137cbf2b5c9 ("crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library"), the aes module (CRYPTO_AES) supports CBC based MACs using the corresponding library functions. To avoid including unneeded functionality, that support honors the existing CRYPTO_CMAC, CRYPTO_XCBC, and CRYPTO_CCM kconfig options. The dependencies are selected if at least one of those is enabled. However, the select statements don't correctly handle the case where CRYPTO_AES=y and (for example) CRYPTO_CMAC=m. In that case the dependencies get selected at level 'm', due to how the kconfig language works. That causes a linker error. Fix this by changing the selection conditions to use '!= n'. A similar issue also exists for CRYPTO_LIB_AES's conditional selection of CRYPTO_LIB_UTILS. The same '!= n' would work, but instead just make CRYPTO_LIB_AES always select CRYPTO_LIB_UTILS. CRYPTO_LIB_UTILS is lightweight, and it's needed by most AES modes and many other things. Fixes: 7137cbf2b5c9 ("crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library") Fixes: 309a7e514da7 ("lib/crypto: aes: Add support for CBC-based MACs") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260709022954.45113-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit f1ca750c0510bdbb504bf084d2f196ef2af92ea6 Author: Laxman Acharya Padhya Date: Fri Jul 10 23:10:03 2026 +0545 Bluetooth: btrtl: validate firmware patch bounds commit 609c5b04a28dc1b0f3af6a7bc93055135b2d2059 upstream. rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch. Fixes: db33c77dddc2 ("Bluetooth: btrtl: Create separate module for Realtek BT driver") Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1b41cbe05b184f8861712f0806cc0c4f5d8c6dfe Author: Asim Viladi Oglu Manizada Date: Mon Jul 6 09:44:10 2026 +0000 net: openvswitch: reject oversized nested action attrs commit 3f1f755366687d051174739fb99f7d560202f60b upstream. Open vSwitch stores generated flow actions as nlattrs, whose nla_len field is u16. Commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check") allowed the total sw_flow_actions stream to grow beyond 64 KiB, which is valid, but also removed the last guard preventing a generated nested action attribute from exceeding U16_MAX. An oversized generated container can thus be closed with a truncated nla_len. A later dump or teardown then walks a structurally different stream than the one that was validated. In particular, an oversized nested CLONE/CT action may cause subsequent bytes in the generated stream to be interpreted as independent actions. Keep the larger total-action-stream behavior, but make nested action close reject generated containers that do not fit in nla_len, and return the error through all callers. For recursive SAMPLE, CLONE, DEC_TTL, and CHECK_PKT_LEN builders, trim resource-owning action-list tails in reverse construction order before discarding failed wrappers, so resources copied into the rejected tails are released before the wrappers are removed. Most failed outer wrappers are discarded by truncating actions_len after child resources have been released. CHECK_PKT_LEN also trims its parent after branch resources are gone. SET/TUNNEL close failures unwind their known tun_dst ownership directly, and SET_TO_MASKED has no external ownership and truncates on close failure. Fixes: a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check") Cc: stable@vger.kernel.org Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix Signed-off-by: Asim Viladi Oglu Manizada Reviewed-by: Eelco Chaudron Reviewed-by: Aaron Conole Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260706094336.38639-1-manizada@pm.me Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b7f5bd59ed1c3a950a41130e7e1709d11db5e150 Author: Abhishek Ojha Date: Wed Jul 15 13:04:08 2026 -0400 regulator: ltc3676: Fix incorrect IRQSTAT bit offsets commit 50dce2e2f84b56d8b4b406d97a1543709e8a87f5 upstream. The LTC3676_IRQSTAT_* bit definitions do not match the IRQSTAT (Interrupt Request Status) register layout documented in Table 15 of the LTC3676/LTC3676-1 datasheet: bit 0 - Pushbutton Status Active bit 1 - Hard Reset Occurred bit 2 - PGOOD Timeout Occurred bit 3 - Undervoltage Warning bit 4 - Undervoltage Standby (Fault) Occurred bit 5 - Overtemperature Warning bit 6 - Overtemperature Standby (Fault) Occurred bit 7 - Reserved The driver instead defines these starting at bit 3, one bit higher than the datasheet specifies, which causes ltc3676_regulator_isr() to check the wrong status bits and misreport (or miss) PGOOD timeout, undervoltage and thermal warning/fault conditions. Fix the bit offsets to match the datasheet. Fixes: 37b918a034fe ("regulator: Add LTC3676 support") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Ojha Link: https://patch.msgid.link/20260715170408.295552-1-Abhishek.ojha@savoirfairelinux.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c8874e338d51aa59f12a88442868f49c7c5c4cda Author: Aurelien Jarno Date: Tue Jun 23 22:40:57 2026 +0200 arch/riscv: vdso: remove CFI landing pad from rt_sigreturn commit e4bf6eb4c7b61db1cf24487e14e6ae8755e61e3d upstream. When CONFIG_RISCV_USER_CFI is enabled, the CFI version of the vDSO, has a CFI landing pad instruction at the start of __vdso_rt_sigreturn. This breaks libgcc's unwinding code which matches on the first two instructions. Other unwinders that rely on similar instruction matching may also be affected. Since __vdso_rt_sigreturn is reached as part of signal-return handling rather than via an indirect call/jump from userspace, it does not need a CFI landing pad. Remove it and restore the instruction sequence expected by existing unwinding code. This matches what was done on arm64 in commit 9a964285572b ("arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction") for a similar issue. Cc: stable@vger.kernel.org Fixes: 37f57bd3faea ("arch/riscv: compile vdso with landing pad and shadow stack note") Co-authored-by: Joel Stanley Signed-off-by: Aurelien Jarno Signed-off-by: Joel Stanley Link: https://patch.msgid.link/20260623204058.498120-1-aurelien@aurel32.net [pjw@kernel.org: fixed comment style] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 73a7bdf06dbde81dd937a37456670d96fcce841c Author: Thomas Weißschuh Date: Wed Jul 1 11:21:22 2026 +0200 riscv: vdso: Do not use LTO for the vDSO commit ad6dcfa023762e37962f77ee48e752b7570e9440 upstream. With LTO enabled the compiler assumes that the vDSO functions are not used and optimizes them away completely. Currently this happens to __vdso_clock_getres(), __vdso_clock_gettime(), __vdso_getrandom(), __vdso_gettimeofday() and __vdso_riscv_hwprobe(). Disable LTO for the vDSO, as these functions are hand-optimized anyways. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606301855.WvkSC4kD-lkp@intel.com/ Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-1-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 185bb156c427d0f865d344a6d0eaa02c6d05cc57 Author: Maoyi Xie Date: Sat Jun 27 21:13:13 2026 +0800 wifi: brcmfmac: cyw: fix heap overflow on a short auth frame commit 240c8d2c717b3f8153e7e877b22a82518d78dbdc upstream. brcmf_notify_auth_frame_rx() takes the frame length from the firmware event and copies the frame body with the management header offset subtracted: u32 mgmt_frame_len = e->datalen - sizeof(struct brcmf_rx_mgmt_data); ... memcpy(&mgmt_frame->u, frame, mgmt_frame_len - offsetof(struct ieee80211_mgmt, u)); The only length check is e->datalen >= sizeof(*rxframe), so mgmt_frame_len can be anything from 0 up. offsetof(struct ieee80211_mgmt, u) is 24. When mgmt_frame_len is below that, the subtraction wraps as an unsigned value to a huge length. The memcpy then runs far past the kzalloc'd buffer. A malicious or malfunctioning AP can make the frame short during the external SAE auth exchange, so this is a remotely triggered heap overflow. Reject frames shorter than the management header offset before the copy. Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Link: https://lore.kernel.org/r/178214417708.2368577.16740907093694208834@maoyixie.com Cc: stable@vger.kernel.org Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260627131313.3878893-1-maoyixie.tju@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a7584f261e64fe14e45bdf70f343e16c1ee3a037 Author: Dawei Feng Date: Mon Jul 6 22:35:07 2026 +0800 wifi: mac80211: fix memory leak in ieee80211_register_hw() commit 95fc02722edde02946d0d475221f2b2054d3d8ba upstream. If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed. Fixes: 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support") Cc: stable@vger.kernel.org Reviewed-by: Zilin Guan Signed-off-by: Dawei Feng Link: https://patch.msgid.link/20260706143507.146131-1-dawei.feng@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 564e3fce81eb8435d55e134a6e2e967d7c2d0138 Author: Rafael Beims Date: Wed Jun 10 12:00:18 2026 -0300 wifi: mwifiex: fix roaming to different channel in host_mlme mode commit a707e4127c0f893c7a7703500ab56297a5bd2d51 upstream. When host MLME is enabled, mwifiex_cfg80211_authenticate() transmits the authentication frame on a remain-on-channel (ROC) reservation so that the frame is sent on the target BSS's channel. The ROC is only configured when priv->auth_flag is zero. priv->auth_flag is set to HOST_MLME_AUTH_PENDING when the auth frame is queued and advances to HOST_MLME_AUTH_DONE once authentication completes. It is only cleared back to zero on a disconnect, deauth or timeout path; nothing clears it when an association succeeds. It therefore stays at HOST_MLME_AUTH_DONE for the whole connected session. When the station later roams to a BSS on a different channel, the next authentication finds auth_flag != 0, skips the ROC setup, and the auth frame is transmitted on the currently-associated channel instead of the target's channel. Authentication times out on the new AP and the device stays connected to the original AP. Gate the ROC setup on HOST_MLME_AUTH_PENDING instead of on auth_flag being completely clear. This re-arms the remain-on-channel for every new authentication attempt, while still suppressing a redundant ROC during the multi-frame SAE exchange, where auth_flag stays PENDING between the commit and confirm frames. This change was tested in 3 different devices: Verdin AM62 (IW412 SD-UART) - (16.92.21.p142) Verdin iMX8MM (W8997 SD-SD) - (16.68.1.p197) Verdin iMX8MP (W8997 SD-UART) - (16.92.21.p137) There following loop tests were performed: 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours. Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Rafael Beims Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260610150021.1018611-1-rafael@beims.me Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 56994852d704535ea354a4627ca667b1b4fa0deb Author: Runyu Xiao Date: Fri Jun 19 15:31:04 2026 +0800 wifi: rt2x00: avoid full teardown before work setup in probe commit 536fb3d739d75a03cb318c0c6fe799425cfea501 upstream. rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack. Fixes: 1ebbc48520a0 ("rt2x00: Introduce concept of driver data in struct rt2x00_dev.") Fixes: 0439f5367c8d ("rt2x00: Move TX/RX work into dedicated workqueue") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260619073104.1809161-1-runyu.xiao@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6eb4cf2fa8997f62c11e0006dc010a1fd89c5a75 Author: Zhiping Zhang Date: Thu Jul 2 15:24:58 2026 -0700 net/mlx5: free mlx5_st_idx_data on final dealloc commit df6134b527a88b3e65ba6ae5073664af091d5fd2 upstream. Workloads that repeatedly allocate and release mkeys carrying TPH steering-tag hints (e.g. churning RDMA MRs) leak one struct mlx5_st_idx_data per cycle; kmemleak flags it as unreferenced and the kmalloc slab grows over time. When the last reference to an ST table entry is dropped, mlx5_st_dealloc_index() removed the entry from idx_xa but the backing mlx5_st_idx_data allocation was never freed. Free idx_data after the xa_erase() so the lifetime of the bookkeeping struct matches the lifetime of the ST entry it tracks. Cc: stable@vger.kernel.org Fixes: 888a7776f4fb ("net/mlx5: Add support for device steering tag") Reviewed-by: Michael Gur Signed-off-by: Zhiping Zhang Reviewed-by: Leon Romanovsky Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260702222507.1234467-1-zhipingz@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0b24b11ecda4de79124cbb74e0debb142e82fc7f Author: Thorsten Blum Date: Sun Jun 14 16:23:56 2026 +0200 powerpc/pseries: fix memory leak on krealloc failure in papr_init commit bd83c98b988d2c560531084e296dbfb530aff829 upstream. When krealloc() fails, free the original esi_buf before returning to avoid a memory leak. Fixes: 3c14b73454cf ("powerpc/pseries: Interface to represent PAPR firmware attributes") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260614142356.658212-2-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit cc5c99b606ffb33349298278ae616b4a24997a5b Author: Luke Wang Date: Wed Jul 15 15:18:14 2026 +0800 mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on resume commit 1db87818bde3d2295613660879378b43a70d31f8 upstream. SDIO devices such as WiFi may keep power during suspend, so the MMC core skips full card re-initialization on resume and directly restores the host controller's ios timing to match the card. For DDR mode, pm_runtime_force_resume() sets DDR_EN before the pin configuration is restored from sleep state. This is related to the SoC IP integration: switching pinctrl setting (changing alt from GPIO to USDHC) impacts the internal loopback path. If pinctrl configures the pad to GPIO function, once DDR_EN is set, the DLL delay will be fixed based on the GPIO function loopback path. When the pinctrl is later changed to USDHC function, the internal loopback path changes, making the original fixed sample point no longer suitable for the current loopback path. This causes persistent read CRC errors on subsequent data transfers. SD/eMMC running in DDR mode are unaffected as they are fully re-initialized from legacy timing after resume. Fix this by restoring the pinctrl state based on current timing mode using esdhc_change_pinstate() before pm_runtime_force_resume(). This ensures the correct pin configuration (e.g., 100/200MHz for UHS modes) is applied before DDR_EN is set. Only restore for non-wakeup devices since wakeup devices kept their active pin state during suspend. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter Reviewed-by: Haibo Chen Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 90dfffc360dfb382c4843980ae3c1b787b638925 Author: Thomas Huth Date: Thu Jul 9 18:43:40 2026 +0200 selftests/landlock: Fix screwed up pointers in the scoped_signal_test commit d793186aa3bb833c878ae6826c87e62c843afaa3 upstream. The scoped_signal_test uses pthread_join(..., (void **)&ret)) in a couple of places, i.e. the return value of the thread is stored in the shape of a "void *" into the memory location of &ret. Pointers are 64-bit on modern computers, but the ret variable is declared as a simple "enum thread_return" which is only 32 bits. So the pthread_join() will overflow the ret variable by 4 byte. The problem is very visible on big endian systems like s390x where the test is failing: The least significant byte that carries the return code of the thread is not written into the ret variable here, but somewhere else in the stack frame, so the comparison for the right return code is failing here. Fix it by getting rid of the enum and defining the THREAD_* constants and "ret" variables as proper "void *" pointers. This way we can also get rid of some ugly (void *) castings in a couple of spots. Signed-off-by: Thomas Huth Link: https://patch.msgid.link/20260709164340.339656-1-thuth@redhat.com Cc: stable@vger.kernel.org Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads") [mic: Add clang-format markups] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 19a1785250c76761a0e9e8129659740f38d98a74 Author: Thomas Huth Date: Fri Jul 10 10:16:42 2026 +0200 selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not available commit 5ab1dc6d110db6bee167a32fd94c53ea0e7ad6d2 upstream. MSG_OOB might be disabled in the kernel for unix sockets (by not selecting CONFIG_AF_UNIX_OOB), and in this case the related tests of the scoped_signal_test are currently failing. Add a runtime probe using socketpair() to detect MSG_OOB support and skip the test gracefully if it is unavailable. Signed-off-by: Thomas Huth Link: https://patch.msgid.link/20260710081642.405916-1-thuth@redhat.com Cc: stable@vger.kernel.org Fixes: f34e9ce5f479 ("selftests/landlock: Test signal created by out-of-bound message") Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 4907f4c2d98b97e640191af5bcf2814ee1034b76 Author: Peng Fan Date: Wed Jun 10 22:39:11 2026 +0800 pmdomain: imx: Fix i.MX8MP VC8000E power up sequence commit 25e252bcf1593b420b12a7231d9dd64b885a2ae2 upstream. Per errata[1]: ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX power up/down cycling. Description: VC8000E reset de-assertion edge and AXI clock may have a timing issue. Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is de-asserted by HW) Add a bool variable is_errata_err050531 in 'struct imx8m_blk_ctrl_domain_data' to represent whether the workaround is needed. If is_errata_err050531 is true, first clear the clk before powering up gpc, then enable the clk after powering up gpc. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl") Cc: stable@vger.kernel.org Signed-off-by: Peng Fan Reviewed-by: Frank Li Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 331ee3bc4edf9e0301cec11882aa651655671e69 Author: Peng Fan Date: Wed Jun 10 22:39:10 2026 +0800 pmdomain: imx: Fix i.MX8MP power notifier commit 72422525f641f68bed6ca3389d29ee3f41fdea33 upstream. Using imx8mm_vpu_power_notifier() for i.MX8MP is wrong, as it ungates the VPU clocks to provide the ADB clock, which is necessary on i.MX8MM, but on i.MX8MP there is a separate gate (bit 3) for the NoC. So add imx8mp_vpu_power_notifier() for i.MX8MP. Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Peng Fan Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 36c2d7728540252474752172027f0113028ab00c Author: AngeloGioacchino Del Regno Date: Thu Jul 9 10:46:32 2026 +0200 pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check commit a4876f11aa1d076802676e23f8af500706e780e3 upstream. Should probe fail for HW_VOTER type power domains, this driver was unconditionally trying to perform cleanup for DIRECT_CTL domains, but only after checking if the target domain is powered on... with the DIRECT_CTL scpsys_domain_is_on() code again. And there's more: the scpsys_domain_is_on() function is also being unconditionally used in the probe path, for any power domain that has flag MTK_SCPD_KEEP_DEFAULT_OFF! This bug was never experienced by anyone because the HWV domains never failed probe, and because none of those is declared with the aforementioned flag - but it's still something critical. In order to fix this, add a check for MTCMOS Type and, based on that, call the correct functions for an "is on" check, and also do the same for the cleanup path, calling the correct functions for the "power off" action. For the latter, since there's a call to pm_genpd_remove() right before calling power_off, be cautious and add a variation of the power off functions (with a _internal suffix) for those to get a pointer to scpsys_domain instead of one to generic_pm_domain as, even if that's still working, this is way too much fragile and would break at some point. Fixes: 88914db077b6 ("pmdomain: mediatek: Add support for Hardware Voter power domains") Signed-off-by: AngeloGioacchino Del Regno Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4ba6d7166750d0b810c6cfc0b1df7585f513b48c Author: Guoniu Zhou Date: Tue Jun 9 14:26:41 2026 +0800 pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI commit 99611233f8cda833169fa6487d5dacdf189e5cb0 upstream. The MIPI DSI and CSI domains share control bits for clock and reset, which can lead to incorrect behavior if one domain disables the shared resource while the other is still active. To fix the issue, introduce a shared MIPI PHY power domain to own the common resources and make DSI and CSI its subdomains. This ensures the shared bits are properly managed and not disabled while still in use. Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Frank Li Reviewed-by: Peng Fan Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c17f06d8a085d6be58b544a440ce243f5e441a60 Author: Farhad Alemi Date: Mon Jul 6 10:20:23 2026 +0200 cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed commit b983c56426383e4a06fa5970c4e33cee879b1482 upstream. Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. Link: https://lore.kernel.org/all/CA+0ovCiEz6SP_sn3kN4Tb+_oC=eHMXy_Ffj=usV3wREdQrUtww@mail.gmail.com/ Fixes: ae1c802382f7 ("cpuset: apply cs->effective_{cpus,mems}") Closes: https://lore.kernel.org/linux-mm/CA+0ovCgxbZkXa+OU8w3s84R3KNPNxxRfmsNR-udh+afQBbGNmw@mail.gmail.com/ Suggested-by: Gregory Price Suggested-by: Waiman Long Acked-by: Waiman Long Signed-off-by: Farhad Alemi Cc: Andrew Morton Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Rasmus Villemoes Cc: Zi Yan Cc: Tejun Heo Cc: Ridong Chen Cc: Johannes Weiner Cc: "Michal Koutný" Cc: [ david: add a comment, slightly rephrase description ] Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit f45c8d3818da7861ac78f631b5be80f7403f9760 Author: Hui Wang Date: Tue Jul 7 16:23:48 2026 +0800 selftests/rseq: Fix a building error for riscv arch commit a2ac823d8a228e392bc6a79ea63b550ab84a55b2 upstream. RISC-V rseq selftests include asm/fence.h from tools/arch/riscv, but the rseq Makefile only adds tools/include in the CFLAGS, this results in the building failure both for native and cross build: In file included from rseq.h:131, from rseq.c:37: rseq-riscv.h:11:10: fatal error: asm/fence.h: No such file or directory To fix it, add the matching tools/arch/$(ARCH)/include path in the CFLAGS and derive ARCH from SUBARCH for standalone native builds where ARCH is not set. Fixes: c92786e179e0 ("KVM: riscv: selftests: Use the existing RISCV_FENCE macro in `rseq-riscv.h`") Cc: stable@vger.kernel.org Signed-off-by: Hui Wang Link: https://patch.msgid.link/20260707082348.36896-1-hui.wang@canonical.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 28673209eeeab3f3c1abcaded43dac527ca2b58f Author: Gerald Schaefer Date: Tue Jun 30 19:32:14 2026 +0200 s390/mm: Fix type mismatch in get_align_mask(). commit ec84aad4c3594307d103af563991b4415ac5c8ab upstream. Commit 86f48f922ba79 ("s390/mmap: disable mmap alignment when randomize_va_space = 0") introduced get_align_mask() with return type of 'int', while the target field 'info.align_mask' in struct vm_unmapped_area_info is 'unsigned long'. With currently used masks, this should not cause truncation issues, but fix it and return 'unsigned long' to avoid future problems. Fixes: 86f48f922ba79 ("s390/mmap: disable mmap alignment when randomize_va_space = 0") Cc: stable@vger.kernel.org # v6.9+ Signed-off-by: Gerald Schaefer Reviewed-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 83fe36f81200b7a85f8efe0a68a4e58be84d5f64 Author: Heiko Carstens Date: Mon Jun 22 16:31:24 2026 +0200 s390/diag: Add missing array_index_nospec() call to memtop_get_page_count() commit b7577fe4c47a31ca7c99714c53244a44af03cdfe upstream. 'level' is user space controlled and used to read from an array. Add the missing array_index_nospec() call to prevent speculative execution. Cc: stable@vger.kernel.org Fixes: 0d30871739ab ("s390/diag: Add memory topology information via diag310") Signed-off-by: Heiko Carstens Reviewed-by: Mete Durlu Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit dd0160a0842337f12e7694d68b184050afc6d3a4 Author: Crystal Wood Date: Mon Jun 8 23:54:30 2026 -0500 tracing/osnoise: Call synchronize_rcu() when unregistering commit fe58f457ad8d0a2bef4e053cfecca4b5cd266b1a upstream. This ensures that any RCU readers traversing the instance list have finished, before releasing the reference on the tracer that the instance points to. Cc: stable@vger.kernel.org Fixes: a6ed2aee54644 ("tracing: Switch to kvfree_rcu() API") Link: https://patch.msgid.link/20260609045430.1589786-1-crwood@redhat.com Suggested-by: Steven Rostedt Signed-off-by: Crystal Wood Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d5b2752a17efc165793ae38f2c24b5ed9c04ffde Author: Tao Liu Date: Mon Jul 6 11:27:07 2026 +1200 riscv: Prevent NULL pointer dereference in machine_kexec_prepare() commit 81bbcff0c053c4f5c711c31a9b72fc492bd96c3f upstream. A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt. Fixes: b7fb4d78a6ad ("RISC-V: use memcpy for kexec_file mode") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/kexec/CAO7dBbVftLUhd2qrh7hmijTB3PEPfZAhykCGqEfrPoOcSrrj-w@mail.gmail.com/ Acked-by: Baoquan He Acked-by: Pratyush Yadav Reviewed-by: Nutty Liu Signed-off-by: Tao Liu Link: https://patch.msgid.link/20260705232706.30265-2-ltao@redhat.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 648d4317326e6aa3f8c05cbf0fd14cc2eba6ca99 Author: Michael Bommarito Date: Thu Jul 9 22:28:37 2026 -0400 drbd: reject data replies with an out-of-range payload size commit bd910a7660d280595ef94cb6d193951d855d330f upstream. recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required. Fixes: b411b3637fa7 ("The DRBD driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Christoph Böhmwalder Link: https://patch.msgid.link/20260710022837.3738461-1-michael.bommarito@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f713d7a7e0f23aff134fc773936063184d9be9e3 Author: TJ Adams Date: Mon Jul 6 14:00:54 2026 -0700 ata: libata-core: Allow capacity transition to zero for locked drives commit 793bf193b18e9bff6c4280268bbffd16a5b533e5 upstream. Commit 91842ed844a0 ("ata: libata-core: Set capacity to zero for a security locked drive") introduced setting the device capacity (n_sectors) to zero in ata_dev_configure() if the drive is security locked. However, during runtime revalidation, ata_dev_revalidate() compares the new capacity (now 0) with the old capacity (>0) and detects a mismatch. Since it does not consider the locked status, it returns -ENODEV. This revalidation failure can occur when doing a reset of the PHY (e.g. hard reset) for a controller that has I/Os in flight. The timed out I/Os trigger the SCSI Error Handling (EH) path, which in turn invokes libata device revalidation. If the drive is locked at runtime (e.g. it lost power during reset and relocked), revalidation sees the capacity transition to zero and fails, eventually disabling the device. Fix this by allowing the capacity transition to zero in ata_dev_revalidate() if the drive is reported as security locked by ata_id_is_locked(). Fixes: 91842ed844a0 ("ata: libata-core: Set capacity to zero for a security locked drive") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Terrence Adams Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit f723ea50a96d8670fd8b7e04cc2d4c1a2956835c Author: TJ Adams Date: Mon Jul 6 14:00:53 2026 -0700 ata: libata-core: Skip HPA resize for locked drives commit 917d0a4b95ea7ba01ed6296fb808f752d5d81107 upstream. Skip HPA resize in ata_hpa_resize() if the drive is security locked. If the drive is locked, the command to read the native max address fails with -EACCES, which currently causes the sticky quirk ATA_QUIRK_BROKEN_HPA to be set on the device. Setting this sticky quirk causes subsequent revalidations (after the drive is unlocked) to bypass HPA checks, preventing the unlocked drive from exposing its full native capacity without a reboot or device removal. Cc: stable@vger.kernel.org Signed-off-by: Terrence Adams Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit f7628eea9212e185a09df3aea603ca8580b8678d Author: Reinette Chatre Date: Mon Jul 6 15:46:23 2026 -0700 fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list commit b9f089723aee892efc77c349ae47a6b452b293c4 upstream. A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID. Fixes: e0bdfe8e36f3 ("x86/intel_rdt: Support creation/removal of pseudo-locked region") Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://patch.msgid.link/551432dd7e624a862b8e58314c38aaba0afff3e9.1783377598.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman commit fa5c7c313018220bb5df6aea619cc6ad11484363 Author: Tony Luck Date: Mon Jul 6 15:46:21 2026 -0700 fs/resctrl: Free mon_data structures on rdt_get_tree() failure commit ca0676ae2e1a23ac3e858224fc630b99f9e216ea upstream. If mkdir_mondata_all() or a subsequent call in rdt_get_tree() fails, the mon_data structures allocated by mon_get_kn_priv() are leaked. Add mon_put_kn_priv() to the out_mongrp error path to free the mon_data structures. Fixes: 2a6566038544 ("x86/resctrl: Expand the width of domid by replacing mon_data_bits") Closes: https://lore.kernel.org/lkml/5d38c1fb-8f91-472b-8897-24b2f50c772b@intel.com/ Reported-by: Reinette Chatre Signed-off-by: Tony Luck Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Chen Yu Reviewed-by: Ben Horgan Cc: Link: https://patch.msgid.link/433623b7e3316ffd52323255d1aa4f156ad97cb1.1783377598.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman commit 901a489d89ee9c854624c8444090e38e70aed234 Author: Jinjie Ruan Date: Wed Jun 10 15:52:02 2026 +0800 cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable() commit f9a82544c7174851f5c7524622f5966dcafd3a47 upstream. On arm64, when booting with `maxcpus` greater than the number of present CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present' but have not yet been registered via register_cpu(). Consequently, the per-cpu device objects for these CPUs are not yet initialized. In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling _cpu_up() for these unregistered CPUs eventually leads to sysfs_create_group() being called with a NULL kobject (or a kobject without a directory), triggering the following warning in fs/sysfs/group.c: WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181 [...] Call trace: internal_create_group+0x41c/0x4bc (P) sysfs_create_group+0x18/0x24 topology_add_dev+0x1c/0x28 cpuhp_invoke_callback+0x104/0x20c __cpuhp_invoke_callback_range+0x94/0x11c _cpu_up+0x200/0x37c When booting with ACPI, arm64 smp_prepare_cpus() currently sets all enumerated CPUs as "present" regardless of their status in the MADT. This causes issues with SMT hotplug control. For instance, with QEMU's "-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as follows: 1. The first four CPUs: `Enabled` set but `Online Capable` not set. 2. The remaining four CPUs: `Online Capable` set but `Enabled` not set to support potential hot-plugging. Fix this by: 1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC entry before calling set_cpu_present() during SMP initialization. 2. Properly managing the present mask in acpi_map_cpu() and acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with other architectures like x86 and LoongArch. 3. Update the arm64 CPU hotplug documentation to no longer state that all online-capable vCPUs are marked as present by the kernel at boot time. This ensures that only physically available or explicitly enabled CPUs are in the present mask, keeping the SMT control logic consistent with the actual hardware state. Cc: Catalin Marinas Cc: Jonathan Cameron Cc: James Morse Cc: Yicong Yang Cc: stable@vger.kernel.org Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure Fixes: eed4583bcf9a ("arm64: Kconfig: Enable HOTPLUG_SMT") Reviewed-by: Catalin Marinas Suggested-by: Catalin Marinas Signed-off-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit c3f200efb45470417824a36fcd2147bd8f5fb78b Author: Jinjie Ruan Date: Wed Jun 10 15:52:01 2026 +0800 arm64: smp: Fix hot-unplug tearing by forcing unregistration commit 18a4e5cf633fad5c40ac9d936c51bf38db68796d upstream. Sashiko review pointed out the following issue[1]. Commit eba4675008a6 ("arm64: arch_register_cpu() variant to check if an ACPI handle is now available.") introduced architectural safety blocks inside arch_unregister_cpu(). If a hot-unplug operation is determined to be a physical hardware removal (where _STA evaluates to !ACPI_STA_DEVICE_PRESENT), or if firmware evaluation fails, it aborts the unregistration transaction early to protect unreadied arm64 infrastructure. However, returning early from arch_unregister_cpu() causes a catastrophic state tearing because the generic ACPI layer (acpi_processor_post_eject()) unconditionally continues its cleanup flow. This leaves the stale sysfs device leaked in the memory, deadlocking any subsequent hot-add attempts on the same CPU. Fix it by simplifying arch_unregister_cpu() to always proceed with the unregistration, as a pr_err_once() warning is sufficient to make it more visible for currently not supported physical CPU removal. Also remove the redundant NULL check on acpi_handle as it cannot be NULL when calling arch_unregister_cpu(). Cc: Catalin Marinas Cc: Jonathan Cameron Cc: James Morse Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260520022023.126670-1-ruanjinjie@huawei.com [1] Fixes: eba4675008a6 ("arm64: arch_register_cpu() variant to check if an ACPI handle is now available.") Suggested-by: Catalin Marinas Signed-off-by: Jinjie Ruan Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit f50d87f9752791380f31b03d69a18377907fc465 Author: Zhu Lingshan Date: Wed Jul 1 16:08:12 2026 +0800 amdkfd: properly free secondary context id commit a88419af8dbd5abf8b1dfdfd9346376bce5413b4 upstream. Function kfd_process_free_id() should skip over the primary kfd process because its context id is fixed assigned, not allocated through the ida table. This function should only work on secondary contexts. Fixes: fac682a1d1af ("amdkfd: identify a secondary kfd process by its id") Signed-off-by: Zhu Lingshan Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 8799ba6fb6a48438aea20c82e74c2f2a3d2b2e7a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 109241d9880488aafd8e104832b4d4859ad57244 Author: Théo Lebrun Date: Thu Jul 2 17:37:02 2026 +0200 net: macb: drop in-flight Tx SKBs on close commit 27f575836cfebbf872dec020428742b10650a955 upstream. The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty. Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver") Cc: stable@vger.kernel.org Reviewed-by: Nicolai Buchwitz Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20260702-macb-drop-tx-v4-1-1c833eebdbc8@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 94fe0ab01b480b52bd8f977edbd845ef375d69fd Author: Dust Li Date: Tue Jul 7 15:43:18 2026 +0800 dibs: loopback: validate offset and size in move_data() commit 78237e3c0720fcc6eb9b87e90fd70f63eeca886f upstream. The loopback move_data() performs a memcpy into the registered DMB without checking whether offset + size exceeds the DMB length. Unlike real ISM hardware, which enforces memory region bounds natively, the software loopback has no such protection. A peer-supplied out-of-bounds offset or oversized write would result in an OOB write past the allocated kernel buffer. Add an explicit bounds check before the memcpy to reject such requests with -EINVAL. Fixes: f7a22071dbf3 ("net/smc: implement DMB-related operations of loopback-ism") Cc: stable@vger.kernel.org Reported-by: Federico Kirschbaum Signed-off-by: Dust Li Reported-by: Baul Lee Link: https://patch.msgid.link/20260707074318.1448662-1-dust.li@linux.alibaba.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit c39087ad0b97fc11a3b058dfc8db9fd370762cb9 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Jul 3 17:36:33 2026 +0900 macsec: don't read an unset MAC header in macsec_encrypt() commit f5089008f90c0a7c5520dff3934e0af00adf322d upstream. macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") for exactly this purpose. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260703083634.2035145-1-4ncienth@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 6335ab62d5fc9ed875279238233fba3462c168f5 Author: Yizhou Zhao Date: Thu Jul 2 19:28:36 2026 +0800 ipvs: reset full ip_vs_seq structs in ip_vs_conn_new commit 2975324d164c552b028632f107b567302863b7f6 upstream. Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing "reset struct ip_vs_seq" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later. Fixes: 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit e5d0bb8871668f20de8f3c94b5ae3f372346bc6e Author: Yizhou Zhao Date: Mon Jul 6 18:16:24 2026 +0800 ipvs: use parsed transport offset in SCTP state lookup commit 2f75c0faa3361b28e36cc0512b3299e163e25789 upstream. set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset. Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260705123040.35755-1-zhaoyz24@mails.tsinghua.edu.cn/ Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude Code:GLM-5.2 Signed-off-by: Yizhou Zhao Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 21a537606fe35be2b85971a5fd35c0023b6ef98f Author: Shuangpeng Bai Date: Tue Jun 30 15:48:56 2026 -0400 llc: fix SAP refcount leak in llc_ui_autobind() commit 660667cd406648bbaffbd5c0d897c2263a852f11 upstream. llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260630194856.1036497-1-shuangpeng.kernel@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 680d9dcbf428317250ea269ace4dd670610f38e0 Author: Nirmoy Das Date: Tue Jun 30 09:51:57 2026 -0700 selftests: net: make busywait timeout clock portable commit dd6a23bac306b7aa322e0aaccb60c6e32a198fb3 upstream. loopy_wait() expects millisecond timestamps. However, Ubuntu Resolute can use uutils date, where `date -u +%s%3N` returns seconds plus full nanoseconds instead of a 3-digit millisecond field. This makes busywait expire too early and can make vlan_bridge_binding.sh read a stale operstate. Fixes: 25ae948b4478 ("selftests/net: add lib.sh") Cc: stable@vger.kernel.org # 6.8+ Link: https://github.com/uutils/coreutils/issues/11658 Signed-off-by: Nirmoy Das Link: https://patch.msgid.link/20260630165157.3814871-1-nirmoyd@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 23d917acd9c9a9fd999688ec3fdde7aa58ab8a14 Author: Dawei Feng Date: Tue Jun 30 15:16:25 2026 +0800 octeontx2-pf: fix SQB pointer leak on init failure commit 62e7df6d042aeebd5efb581074e28865c04477be upstream. otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed. Fixes: caa2da34fd25 ("octeontx2-pf: Initialize and config queues") Cc: stable@vger.kernel.org Reviewed-by: Ratheesh Kannoth Signed-off-by: Dawei Feng Link: https://patch.msgid.link/20260630071625.349996-1-dawei.feng@seu.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit d8b5b66388a51febe4b8505b0ecd9da15b4ba639 Author: Yousef Alhouseen Date: Wed Jul 1 18:42:22 2026 +0200 mac802154: remove interfaces with RCU list deletion commit 539dfcf69105d8d3d4d677b71de6e5ede2e6dfa0 upstream. Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed. Fixes: 592dfbfc72f5 ("mac820154: move interface unregistration into iface") Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Reviewed-by: Kuniyuki Iwashima Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260701164222.9094-1-alhouseenyousef@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ae5347f3db1782c6118f6cc0d9fd8b1d43397db3 Author: Gerald Schaefer Date: Tue Jun 23 19:44:06 2026 +0200 s390/monwriter: Reject buffer reuse with different data length commit 2995ccec260caa9e85b3301a4aba1e66ed80ad74 upstream. When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records. Cc: stable@vger.kernel.org Signed-off-by: Gerald Schaefer Reviewed-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit b321a046d7717225c07ba3f4b7b0a4758c2f9d58 Author: Haoxiang Li Date: Tue Jun 23 15:37:44 2026 +0800 irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure commit 1358126fbed104e5657955d3ba029b283687ba02 upstream. imsic_early_acpi_init() allocates a firmware node before setting up the IMSIC state. If imsic_setup_state() fails, the function returns without freeing the allocated fwnode. Free the fwnode and clear the global pointer on this error path, matching the cleanup already done when imsic_early_probe() fails. [ tglx: Use a common cleanup path instead of copying code around ] Fixes: fbe826b1c106 ("irqchip/riscv-imsic: Add ACPI support") Signed-off-by: Haoxiang Li Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260623073744.2009137-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman commit 23afc3786acf359c135093893fb43a436768c832 Author: Zi Yan Date: Mon Jun 22 11:30:42 2026 -0400 mm/compaction: handle free_pages_prepare() properly in compaction_free() commit 7da7d599b8a83271c464adfd5ef160202b470570 upstream. free_pages_prepare() can fail but compaction_free() does not handle the failure case. Failed pages should not be added back to cc->freepages for future use, since they can be either PageHWPoison or free_page_is_bad() and might cause data corruption. Link: https://lore.kernel.org/20260622-handle_free_pages_prepare_in_compaction_free-v1-1-fcf3b14abcf7@nvidia.com Fixes: 733aea0b3a7b ("mm/compaction: add support for >0 order folio memory compaction.") Signed-off-by: Zi Yan Reviewed-by: Vlastimil Babka (SUSE) Acked-by: Johannes Weiner Reviewed-by: Baolin Wang Reviewed-by: Lance Yang Cc: Brendan Jackman Cc: Jiaqi Yan Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 91b4d76dd07f1a1f20f73dfebb42ba04ac911a56 Author: Martin Kaiser Date: Tue Jun 30 21:40:03 2026 +0200 riscv: probes: save original sp in rethook trampoline commit bc7b086a45521a986a49045907f017e3e46c763e upstream. Reading a word from the stack in a kretprobe crashes a risc-v kernel. $ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable Unable to handle kernel paging request at virtual address 0000000200000128 ... [] regs_get_kernel_stack_nth+0x26/0x38 [] process_fetch_insn+0x3ee/0x760 [] kretprobe_trace_func+0x116/0x1f0 [] kretprobe_dispatcher+0x4a/0x58 [] kretprobe_rethook_handler+0x5e/0x90 [] rethook_trampoline_handler+0x70/0x108 [] arch_rethook_trampoline_callback+0x12/0x1c [] arch_rethook_trampoline+0x48/0x94 [] tty_write+0x1a/0x30 In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value. arch_rethook_trampoline saves the registers from the probed function in a struct pt_regs. sp is not saved. Instead, sp is decremented for arch_rethook_trampoline's local stack. Fix this crash and save the original sp along with the other registers. Use a0 as a temporary register, it is overwritten anyway. Cc: stable@vger.kernel.org Fixes: c22b0bcb1dd02 ("riscv: Add kprobes supported") Signed-off-by: Martin Kaiser Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260630194010.1824039-1-martin@kaiser.cx [pjw@kernel.org: added Fixes tag; cc'ed stable] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit b770fcfcdced569bcf7c6982aeea8c3d11a21c2b Author: HyeongJun An Date: Fri Jun 19 21:27:46 2026 +0900 hwmon: (asus_atk0110) Check package count before accessing element commit e2735b39f044bad7bf2017aef248935525bc0b97 upstream. atk_ec_present() walks the management group package returned by the GGRP ACPI method and, for each sub-package, reads its first element: id = &obj->package.elements[0]; if (id->type != ACPI_TYPE_INTEGER) without checking that the sub-package is non-empty. ACPICA allocates the element array with exactly package.count entries, so for a sub-package with a zero count this reads past the allocation. The sibling function atk_debugfs_ggrp_open() performs the same access but skips empty packages with a package.count check first. Add the same check to atk_ec_present() so a malformed firmware package cannot trigger an out-of-bounds read. Fixes: 9e6eba610c2e ("hwmon: (asus_atk0110) Enable the EC") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://lore.kernel.org/r/20260619122746.721981-1-sammiee5311@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3034e5d67ea66d9a6256e0f1c9420e5614b1b287 Author: Haoxiang Li Date: Wed Jun 24 14:59:55 2026 +0800 net: ipa: fix SMEM state handle leaks in SMP2P init commit 96ca1e658ae459276292bd6d971ab5d8c7e0379a upstream. ipa_smp2p_init() acquires two Qualcomm SMEM state handles with qcom_smem_state_get(). However, neither the init error paths nor ipa_smp2p_exit() release them. Release both handles with qcom_smem_state_put() in the init error paths and in ipa_smp2p_exit(). Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Larysa Zaremba Reviewed-by: Alex Elder Link: https://patch.msgid.link/20260624065955.2822765-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 77f0023f22f6a2616ae128e9c93961b24ae52611 Author: Maoyi Xie Date: Thu Jun 25 14:17:28 2026 +0800 net: wwan: iosm: bound device offsets in the MUX downlink decoder commit 526b8ef54668780c8f69e0211c342763d5dcbad1 upstream. mux_dl_adb_decode() walks a chain of aggregated datagram tables using offsets and lengths taken from the modem. first_table_index, next_table_index, table_length, datagram_index and datagram_length are all device supplied le values. Only first_table_index was checked, and only for being non zero. The decoder then formed adth = block + adth_index and read the table header and the datagram entries with no bound against the received skb. A modem that reports an index or a length past the downlink buffer makes the decoder read out of bounds. The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most that, so skb->len is the real limit, but none of these in band offsets were checked against it. The table chain is also followed with no forward progress check. The loop takes the next table from adth->next_table_index and stops only when that reaches zero. A modem can stage two tables that point at each other, so the loop never ends. It runs in softirq and clones the skb on every pass. Validate every device offset and length against skb->len before use. The block header must fit. Each table header, on entry and after every next_table_index, must lie inside the skb. The datagram table must fit. Each datagram index and length must stay inside the skb. The header padding must not exceed the datagram length so the receive length does not wrap. Require each next_table_index to move forward so the chain cannot cycle. This was reproduced under KASAN as a slab out of bounds read on a normal downlink receive once the iosm net device is up. Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") Suggested-by: Loic Poulain Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Simon Horman Reviewed-by: Loic Poulain Link: https://patch.msgid.link/178236824878.3259367.5389624724479864947@maoyixie.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d43efd1b5d976203e6f1ef26f67e8b1a7bc2751b Author: Bryam Vargas Date: Mon Jun 22 22:23:45 2026 -0500 ata: libata-core: Reject an invalid concurrent positioning ranges count commit 533a0b940f901c15e5cbbd4b5d66e871c209e8ce upstream. ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there. Suggested-by: Damien Le Moal Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log") Fixes: c745dfc541e7 ("libata: fix reading concurrent positioning ranges log") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 7ba60286ed14d3162cbb705b988779fdb53811a5 Author: Wentao Liang Date: Thu Jun 25 22:18:37 2026 +0800 ata: pata_pxa: Fix DMA channel leak on probe error commit fcaf242e7fc406e78f444a35441e3b58f5e28781 upstream. When dmaengine_slave_config() fails, the DMA channel acquired by dma_request_chan() is not released before returning the error, leaking the channel reference. Fix by adding dma_release_channel() in the error path. The ata_host_activate() error path already correctly releases the DMA channel. Cc: stable@vger.kernel.org Fixes: 88622d80af82 ("ata: pata_pxa: dmaengine conversion") Signed-off-by: Wentao Liang Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 299739909c486bcea7445f5c3b066fdbc0d2df96 Author: Bryam Vargas Date: Fri Jun 19 21:54:02 2026 -0500 ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD commit 462775c620197adaabc983ce847e5b9878ff4cb0 upstream. The PNY CS900 1TB SSD (Phison PS3111-S11, DRAM-less) drops off the bus after entering Device-Initiated Slumber during idle. With the default med_power_with_dipm policy the link goes down (SStatus 1 SControl 300) and does not recover, forcing the filesystem read-only. Forcing max_performance keeps the link stable across prolonged idle. Add a NOLPM quirk so link power management is disabled for this drive specifically, leaving it intact for other devices on the host. Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit ae0265f0a95aaacef59d560a3e1ea36db8be9a52 Author: Dawei Feng Date: Mon Jun 29 14:40:49 2026 +0800 net/mlx5: HWS, fix matcher leak on resize target setup failure commit bb09d0e64ecaa0aa0f7d1133a1696ed74dead295 upstream. hws_bwc_matcher_move() allocates a replacement matcher before setting it as the resize target. If mlx5hws_matcher_resize_set_target() fails, the replacement matcher is not attached anywhere and is leaked. Fix the leak by destroying the replacement matcher before returning from the resize-target failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have a mlx5 HWS-capable device to test with, no runtime testing was able to be performed. Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Reviewed-by: Yevgeny Kliteynik Acked-by: Tariq Toukan Link: https://patch.msgid.link/20260629064049.3852759-1-dawei.feng@seu.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e3d325c0bdb7bc5d1b4cc8d8441d79794cd03729 Author: Bryam Vargas Date: Fri Jun 19 04:38:20 2026 -0500 orangefs: keep the readdir entry size 64-bit in fill_from_part() commit 18227a6bc98bd0ba96ed3ce9d5b28776a5a28dfc upstream. fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client. Fixes: 480e3e532e31 ("orangefs: support very large directories") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260619-b4-disp-50d2bd59-v1-1-ce332969b4a2@proton.me Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit aac98ec816b080cc49c4dd55e8e61ffdfae73aee Author: Masami Hiramatsu (Google) Date: Thu Jun 25 08:34:47 2026 +0900 tracing/probes: Fix double addition of offset for @+FOFFSET commit 9a667b7750dda88cbf1cca96a53a2163b2ee71f7 upstream. Since commit 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") wrongly use @offset local variable during the parsing, the offset value is added twice when dereferencing. Reset the @offset after setting it in FETCH_OP_FOFFS. Link: https://lore.kernel.org/all/178217905962.643090.1978577464942171332.stgit@devnote2/ Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") Signed-off-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4a97d08d4ace292afb144d119657abf3413538ea Author: Joshua Crofts Date: Mon Jun 29 21:17:39 2026 +0200 hwmon: (max1619) add missing 'select REGMAP' to Kconfig commit 943a749bdffdd2132fab9240db890e07d93e1fcf upstream. The Kconfig entry for the MAX1619 sensor doesn't contain a `select REGMAP` parameter, causing build failures if regmap isn't selected previously during the build process. Fixes: f8016132ce49 ("hwmon: (max1619) Convert to use regmap") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Link: https://lore.kernel.org/r/20260629-add-kconfig-deps-v1-1-8104df929b1a@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6ee183d89261bf1d1cf9f06d80a40dab8f36ee55 Author: David Lee Date: Wed Jul 1 11:44:28 2026 +0000 fhandle: reject detached mounts in capable_wrt_mount() commit 6c732471740bc2ac9b0946134f9f551dc75f4369 upstream. The recent fhandle RCU fix moved the mount namespace capability check into capable_wrt_mount(), so a non-NULL mnt_namespace survives the ns_capable() dereference. The helper still assumes the later READ_ONCE(mount->mnt_ns) must be non-NULL because may_decode_fh() checked is_mounted() first. That assumption is not stable. A detached mount from open_tree(..., OPEN_TREE_CLONE) can be dissolved on fput while open_by_handle_at() is between those checks, and umount_tree() can clear mount->mnt_ns. If the helper observes NULL, it dereferences mnt_ns->user_ns and panics. Return false when the RCU read observes a detached mount. This keeps the relaxed permission path conservative: a mount no longer attached to a namespace cannot authorize open_by_handle_at() access. Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: LLM Link: https://patch.msgid.link/20260701114438.24431-1-david.lee@trailofbits.com Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2dcebbd1ad2e180fe7b98bf346ced69a872e11e6 Author: Bryam Vargas Date: Thu Jun 25 04:51:19 2026 -0500 net/sched: sch_taprio: Replace direct dequeue call with peek and qdisc_dequeue_peeked commit e056e1dfcddca877dd46d704e8ec9860cfc9ec44 upstream. When taprio's software path peeks a non-work-conserving child qdisc, the child stashes the peeked skb in its gso_skb; taprio_dequeue_from_txq() then takes the packet with a direct child ->dequeue() call, which ignores that stash, orphans the peeked skb and desyncs the child's qlen/backlog. With a qfq child this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_red and sch_sfb now do. The helper returns the child's stashed skb first and is a no-op when there is none, so a work-conserving child is unaffected and the gated path now consumes the skb whose length was charged to the budget. Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler") Cc: stable@vger.kernel.org Cc: Vladimir Oltean Signed-off-by: Bryam Vargas Reviewed-by: Victor Nogueira Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260625-b4-disp-31bcb279-v1-1-85c40b83c529@proton.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fffeb2ab5eeb823d4c2330571a098f63237c9049 Author: Bryam Vargas Date: Thu Jun 25 04:51:20 2026 -0500 net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked commit 54f6b0c843e228d499eb4b6bbb89df68cad9ad5d upstream. multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected. Fixes: 77be155cba4e ("pkt_sched: Add peek emulation for non-work-conserving qdiscs.") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Victor Nogueira Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260625-b4-disp-31bcb279-v1-2-85c40b83c529@proton.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b99e890e6b32ffa11c145a16fefcf2c7137a9578 Author: Andrea Righi Date: Fri Jun 26 18:32:18 2026 +0200 net: lan743x: Initialize eth_syslock spinlock before use commit 39139b1c1c2b614096519b526112c726adb12ff0 upstream. lan743x_hardware_init() calls pci11x1x_strap_get_status() during the PCI11x1x probe sequence. That helper acquires the Ethernet subsystem hardware lock via lan743x_hs_syslock_acquire(), which relies on adapter->eth_syslock_spinlock to serialize access. The spinlock is currently initialized only after the strap status is read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized spinlock can trip the spinlock debug check. Fix by initializing adapter->eth_syslock_spinlock before reading the strap status so the probe path never attempts to lock an uninitialized spinlock. Fixes: 46b777ad9a8c ("net: lan743x: Add support to SGMII 1G and 2.5G") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Andrea Righi Reviewed-by: David Thompson Reviewed-by: Thangaraj Samynathan Link: https://patch.msgid.link/20260626163218.3591486-1-arighi@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ca096be8de31256594a67c78b6e0eee89a7ddc89 Author: Haoxiang Li Date: Thu Jun 25 08:48:34 2026 +0800 fsl/fman: Free init resources on KeyGen failure in fman_init() commit d288efa2b94abc2e45a061fceb156b4f4e5b37be upstream. fman_muram_alloc() allocates initialization resources before initializing the KeyGen block. If keygen_init() fails, the function returns -EINVAL directly and leaves those resources allocated. Free the initialization resources before returning from the KeyGen failure path. Fixes: 7472f4f281d0 ("fsl/fman: enable FMan Keygen") Cc: stable@kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Pavan Chebbi Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260625004834.3394389-1-haoxiang_li2024@163.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 7ee43ec8e6774774abbe9dc3027225e01bc964a5 Author: Runyu Xiao Date: Fri Jun 19 09:59:38 2026 +0800 hwmon: (occ) unregister sysfs devices outside occ lock commit e31408734332b8cc611342cdaaab6ba492180156 upstream. occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device. Fixes: 849b0156d996 ("hwmon: (occ) Delay hwmon registration until user request") Fixes: ac6888ac5a11 ("hwmon: (occ) Lock mutex in shutdown to prevent race with occ_active") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://lore.kernel.org/r/20260619015938.494464-1-runyu.xiao@seu.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8519e89c7f4d7e1c19d18136efc689afe6a71b9a Author: Xu Rao Date: Thu Jun 25 21:29:03 2026 +0800 ACPI: TAD: Check AC wake capability before enabling wakeup commit 8522d806d84e2c3816c275ae6dd79e124c1b3dac upstream. ACPI_TAD_AC_WAKE is a non-zero bit definition, so testing the macro itself is always true. As a result, every TAD device is initialized as a system wakeup device, including RTC-only devices and devices whose wake capability bits were cleared because _PRW is absent. Test the capability value returned by _GCP instead. This keeps RTC-only TAD devices usable without advertising a wakeup capability that the firmware does not provide. Fixes: 6c711fde3a1c ("ACPI: TAD: Support RTC without wakeup") Cc: All applicable Signed-off-by: Xu Rao Link: https://patch.msgid.link/961A84FF37B50665+20260625132903.2840457-1-raoxu@uniontech.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4140c516473a0e116ab3a73f9320c2aa5800210b Author: Haoxiang Li Date: Wed Jun 24 14:40:13 2026 +0800 net: liquidio: fix BAR resource leak on PF number failure commit c63ee62a3c4ac1a1542f4c1a4b87e2f41df5a496 upstream. If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review. Fixes: 0c45d7fe12c7 ("liquidio: fix use of pf in pass-through mode in a virtual machine") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Larysa Zaremba Link: https://patch.msgid.link/20260624064013.2809570-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1f11a29a3c809949f6a16cc338484b785745f980 Author: Pengpeng Hou Date: Mon Jun 15 14:48:06 2026 +0800 hwmon: (w83793) remove vrm sysfs file on probe failure commit 77b983757280c69b0290811669ff1d31022e5f1d upstream. w83793_probe() creates the vrm sysfs file after creating the VID files when VID support is present. The normal remove path deletes vrm, but the probe error path only removes the sensor, SDA, VID, fan, PWM and temperature files. A later probe failure can therefore leave vrm behind after the driver data has been freed. Remove vrm in the probe error path next to the VID files, matching the normal remove path. Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/r/20260615064806.51139-1-pengpeng@iscas.ac.cn Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8a604fe15d03b687ee3bfa49c5e1ac6743136c5c Author: Pengpeng Hou Date: Mon Jun 15 14:47:31 2026 +0800 hwmon: (w83627hf) remove VID sysfs files on error and remove commit 5264b389c4e02dec214a46c400eb3ab867a7749a upstream. w83627hf_probe() creates cpu0_vid and vrm with device_create_file() when VID information is available. The error path and remove callback only remove the common and optional attribute groups. Those groups do not contain cpu0_vid or vrm, so the files can remain after a later probe failure or after device removal while their callbacks still expect live driver data. Remove the standalone VID sysfs files from both the probe error path and the remove callback. Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/r/20260615064732.48113-1-pengpeng@iscas.ac.cn Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a3020a389cb15f4598d8febf5ae70f0af0579e19 Author: Conor Dooley Date: Wed May 13 18:55:55 2026 +0100 rtc: mpfs: fix counter upload completion condition commit 9792ff8afa9017fe14f436f3ef3cd75f41f9f145 upstream. The condition that needs to be checked for upload completion is the UPLOAD bit in the completion register going low. The original iterations of this driver used a do-while and this was converted to a read_poll_timeout() during upstreaming without the condition being inverted as it should have been. I suspect that this went unnoticed until now because a) the first read was done when the bit was still set, immediately completing the read_poll_timeout() and b) because the RTC doesn't hold time when power is removed from the SoC reducing its utility (I for one keep it disabled). If my first suspicion was true when the driver was upstreamed, it's not true any longer though, hence the detection of the problem. Fixes: 0b31d703598dc ("rtc: Add driver for Microchip PolarFire SoC") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley Tested-by: Valentina Fernandez Link: https://patch.msgid.link/20260513-panhandle-ashy-70c6abf84d59@spud Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit a36b9528b071718962565ddc6b3004f356fbe93b Author: Eric Biggers Date: Thu Jun 18 15:19:21 2026 -0700 fscrypt: Replace mk_users keyring with simple list commit 696c030e1e3438955aba443b308ee8b6faa3983e upstream. Change mk_users (the set of user claims to an fscrypt master key) from a 'struct key' keyring to a simple linked list. It's still a collection of 'struct key' for quota tracking. It was originally thought to be natural that a collection of 'struct key' should be held in a 'struct key' keyring. In reality, it's just been causing problems, similar to how using 'struct key' for the filesystem keyring caused problems and was removed in commit d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key"). Commit d3a7bd420076 ("fscrypt: clear keyring before calling key_put()") fixed mk_users cleanup to be synchronous. But that apparently wasn't enough: the keyring subsystem's redundant locking is still generating lockdep false positives due to the interaction with filesystem reclaim. With the simple list, the redundant locking and lockdep issue goes away. Of course, searching a linked list is linear-time whereas the 'struct key' keyring used a fancy constant-time associative array. But that's fine here, since in practice there's just one entry in the list. In fact the new code is much faster in practice, since it's much smaller and doesn't have to convert the kuid_t into a string to search for it. Reported-by: syzbot+f55b043dacf43776b50c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c Reported-by: Mohammed EL Kadiri Closes: https://lore.kernel.org/keyrings/20260614150041.21172-1-med08elkadiri@gmail.com/ Fixes: 23c688b54016 ("fscrypt: allow unprivileged users to add/remove keys for v2 policies") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260618221921.87896-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 03f1725f91e8ecd5d986ff9f7ff1fdd763813871 Author: Lad Prabhakar Date: Tue Jun 2 20:25:55 2026 +0100 rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error path commit 7e342d87aa8e6b831cf6d21ca41b1f7e032d0fcf upstream. In rtca3_set_alarm(), the setup_failed path attempts to disable the Periodic Interrupt Enable (PIE) bit and wait until it is cleared. However, the polling condition passed to readb_poll_timeout_atomic() uses an incorrect expression: !(tmp & ~RTCA3_RCR1_PIE) As ~RTCA3_RCR1_PIE evaluates to a mask of all bits except PIE, the condition effectively waits for all non-PIE bits to become zero, which is unrelated to the intended operation and is unlikely to ever be true. This causes the poll to time out unnecessarily. Fix the condition to check for the PIE bit itself being cleared: !(tmp & RTCA3_RCR1_PIE) This correctly waits until PIE is deasserted after being cleared. Fixes: d4488377609e3 ("rtc: renesas-rtca3: Add driver for RTCA-3 available on Renesas RZ/G3S SoC") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea # on RZ/G3S Link: https://patch.msgid.link/20260602192559.1791344-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 356077547b1afa34a8ebae77176a577631a89041 Author: Abdun Nihaal Date: Sat Jun 20 11:53:50 2026 +0530 bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() commit a986fde914d88af47eb78fd29c5d1af7952c3500 upstream. If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation. Cc: stable@vger.kernel.org Fixes: 15192a8cf8a8 ("bnx2x: Split the FP structure") Signed-off-by: Abdun Nihaal Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260620062402.89549-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0fd23994ec8c5436d9f0b50848deb87ed933e6b3 Author: Wentao Liang Date: Wed Jun 3 12:06:34 2026 +0000 ipmi: fix refcount leak in i_ipmi_request() commit a3f3859cecacb64f18fd446271ece9a3b3f2d4de upstream. When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref. Cc: stable@vger.kernel.org Fixes: b52da4054ee0 ("ipmi: Rework user message limit handling") Signed-off-by: Wentao Liang Message-ID: <20260603120634.3758747-1-vulab@iscas.ac.cn> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit a338ce41bc933d8f74c39d9b3b6f1d8ca53d9714 Author: Sabrina Dubroca Date: Fri Jun 12 16:11:39 2026 +0200 espintcp: use sk_msg_free_partial to fix partial send commit 007800408002d871f5699bdb944f985896730b8f upstream. sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents. Cc: stable@vger.kernel.org Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Reported-by: Aaron Esau Reported-by: Yiming Qian Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 7be349d4fcc5e065295b83418a22d27a68afbdb6 Author: Matt Fleming Date: Thu May 21 14:06:27 2026 +0100 ipmi: Fix user refcount underflow in event delivery commit 6aa9e61c46465d231e9beddf56af7effd71be682 upstream. ipmi_alloc_recv_msg(user) takes the temporary user reference owned by the receive message, and ipmi_free_recv_msg() drops it again. If event delivery fails after allocating receive messages for earlier users, handle_read_event_rsp() rolls those messages back with ipmi_free_recv_msg(). That rollback path still drops user->refcount explicitly after freeing each message. The extra put can free a user that remains linked on intf->users, so later event delivery may dereference a freed user or trip refcount_t's addition-on-zero warning when ipmi_alloc_recv_msg() tries to acquire another reference. Remove the stale explicit put and the now-dead user assignment. Keep the list_del() and ipmi_free_recv_msg() calls; they are the required rollback operations. Fixes: b52da4054ee0 ("ipmi: Rework user message limit handling") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Matt Fleming Message-ID: <20260521130628.3641050-1-matt@readmodwrite.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit e483da960892c41fa7f0cf0d2fc2410d65a483d6 Author: Hongchen Zhang Date: Thu Jun 25 13:03:49 2026 +0800 LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect() commit 018e9828eb523c638fa3d9bdf0fd4956b74555b2 upstream. When hardware page table walker (PTW) is enabled on LoongArch, the CPU may set _PAGE_DIRTY directly in the page table entry during a write TLB miss, without going through the software TLB store handler. The software TLB store handler (tlbex.S:254) sets both _PAGE_DIRTY and_PAGE_MODIFIED together: ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED) Since hardware PTW only sets _PAGE_DIRTY, the software-only bit, i.e. _PAGE_MODIFIED is left unchanged. This creates a window where a PTE has _PAGE_DIRTY set (hardware knows the page is dirty) but _PAGE_MODIFIED clear (software is unaware). When fork()/clone() triggers copy-on-write, __copy_present_ptes() calls pte_wrprotect(), which unconditionally clears both the _PAGE_WRITE and _PAGE_DIRTY bits: pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY); Since _PAGE_MODIFIED was never set, the dirtiness information is lost completely. Subsequently, when memory pressure triggers page reclaim, page_mkclean() / try_to_unmap() sees the page as clean (i.e. pte_dirty() returns false) and the page may be freed without writeback, causing data corruption. Fix this by propagating the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit in both pte_wrprotect() and pmd_wrprotect() before clearing writeable bits: if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED; The pmd_wrprotect() fix handles the CONFIG_TRANSPARENT_HUGEPAGE case, where pmd entries need the same treatment. This ensures the software dirty tracking bit (checked by pte_dirty() and pmd_dirty(), which read both the _PAGE_DIRTY and _PAGE_MODIFIED bits) is preserved across fork COW write-protection. The issue was found by the LTP madvise09 test case, which exercises page reclaim after "madvise(MADV_FREE), write and fork" operation sequence on private anonymous mappings. Cc: stable@vger.kernel.org Fixes: 09cfefb7fa70 ("LoongArch: Add memory management") Co-developed-by: Tianyang Zhang Signed-off-by: Tianyang Zhang Signed-off-by: Hongchen Zhang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 7bcce38cbebd103a94d9e1d37b87b4e094833758 Author: Xuewen Wang Date: Thu Jun 25 13:03:49 2026 +0800 LoongArch: Fix nr passing in set_direct_map_valid_noflush() commit 70378a710598432f13509bdc16a1c0f06b3ecb53 upstream. set_direct_map_valid_noflush() incorrectly passes 1 to __set_memory() instead of nr. This causes only the first page's attr to be updated when nr > 1. Other architectures all pass nr correctly. Cc: stable@vger.kernel.org Fixes: 0c6378a71574 ("arch: introduce set_direct_map_valid_noflush()") Signed-off-by: Xuewen Wang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c97d44a5bdf9af0ab6e2208c99fc30f0a6dca65c Author: Biju Das Date: Thu Jun 4 10:56:31 2026 +0100 pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64 commit 2b40d72de9354a76f5e3bb71230a4210eaa92849 upstream. period_ticks is used to store PWM period values that can exceed the 32-bit range, so change its type from u32 to u64 to prevent overflow. Cc: stable@kernel.org Fixes: 061f087f5d0b ("pwm: Add support for RZ/G2L GPT") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260604095647.108654-2-biju.das.jz@bp.renesas.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit c270eaa919f697bf07299acdb503e4546c785398 Author: Thomas Weißschuh Date: Mon May 4 08:30:50 2026 +0200 riscv: vdso: Always declare vdso_start symbols [ Upstream commit 499578e22ae0cc33d05803f22e5c71ffb7077b2f ] Make the declarations of vdso_start and its related symbols always visible. With that their users don't have to use ifdeffery but can use the better IS_ENABLED() compile-time checks. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-1-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit fe08be92f2b63e10e0833012542ddaa67cb96306 Author: Marc Zyngier Date: Tue Jul 7 17:29:35 2026 +0100 KVM: arm64: Fix propagation of TLBI level in kvm_pgtable_stage2_relax_perms() commit 8d187d4b33c262c0f3e44842553521151d8629e8 upstream. Assigning the invalidation level (an s8 value) with TLBI_TTL_UNKNOWN (a 32bit signed value) is not ideal, to say the least. Instead of this, only pass TLBI_TTL_UNKNOWN to __kvm_tlb_flush_vmid_ipa_nsh() when we know for sure that we don't have a provided level. Fixes: 100baf0184896 ("KVM: arm64: Ensure level is always initialized when relaxing perms") Reported-by: Mark Brown Reviewed-by: Oliver Upton Link: https://lore.kernel.org/r/akztC7H2IsEKaq4i@sirena.org.uk Link: https://patch.msgid.link/20260707162935.1900874-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit d1d73a3a37b7725a87c1d137865fb228ab7cc75b Author: Pablo Neira Ayuso Date: Wed Jul 1 12:46:57 2026 +0200 netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master on updates commit 278296b69fae5dd951599692cd481bae4995215c upstream. Really cap it to NF_CT_EXPECT_MAX_CNT (255) on updates. The commit ("netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master") only covers creation of helpers, not updates. Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 835a2f9d9f1749995203be3c0c07d27e2aec58f4 Author: Shuicheng Lin Date: Tue Jun 30 19:22:21 2026 +0000 drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n commit f5ef65adf81da3dbce4e692e48c1754c0bb95da0 upstream. When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of xe_pt_svm_userptr_notifier_lock() is compiled out, triggering: drivers/gpu/drm/xe/xe_pt.c:1418:13: warning: 'xe_pt_svm_userptr_notifier_lock' defined but not used [-Wunused-function] The helpers cannot simply be removed in this case: the matching xe_pt_svm_userptr_notifier_unlock() is also referenced from xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must exist in all builds. Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern used by xe_svm_notifier_lock()/_unlock() in xe_svm.h. Fixes: dca6e08c923a ("drm/xe/userptr: Hold notifier_lock for write on inject test path") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/ Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 3359422bf0a1140e96d783a19a397686e580a3ca) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 1b31e160430ca834ef819bc1f3f947b7e5b985a2 Author: Rafael J. Wysocki Date: Tue Jun 30 18:03:03 2026 +0200 ACPICA: Define acpi_ut_safe_strncpy() as strscpy_pad() alias commit 9825cf2cb59fac7480e7fac9eee13ab9af3f1ea8 upstream. Commit 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()") added an #ifdef based on a __KERNEL__ check which is sort of nasty to the acpi_ut_safe_strncpy() definition to unbreak ACPICA tools builds broken by commit 97f7d3f9c9ac ("ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()"). However, that #ifdef effectively produces dead code when tools are built because they don't call acpi_ut_safe_strncpy(). Accordingly, drop the existing definition of acpi_ut_safe_strncpy() and define it as a strscpy_pad() alias. Fixes: 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()") Signed-off-by: Rafael J. Wysocki [ rjw: Tweak the changelog ] Link: https://patch.msgid.link/12941764.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 227dd2eeab0fd6fceaefe4f8c841bc0a50b52f82 Author: Jamal Hadi Salim Date: Tue Jun 30 11:09:22 2026 -0400 net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants commit 6301f6a34ed86fe6f3b7b3211ea069f3677fc559 upstream. This is a followup based on sashiko comments [1] on commit e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF") Use plain rcu_read_lock()/spin_lock() in teql_master_xmit() instead of the _bh variants, since ndo_start_xmit is already invoked with BH disabled by the core stack and the _bh primitives can warn in_hardirq() when xmit is reached through netpoll or a softirq xmit path with hard IRQs disabled. Moves rcu_read_lock() after restart: label + adds rcu_read_unlock() before goto restart (fixes the unbounded RCU hold across retries) [1] https://sashiko.dev/#/patchset/20260628111229.669751-1-jhs%40mojatatu.com Signed-off-by: Jamal Hadi Salim Fixes: e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF") Link: https://patch.msgid.link/20260630150922.238714-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit fcc621f5b25d15f0ff41eec2bf866dd8dd4e2269 Author: Daniel Gibson Date: Sat Jun 27 00:02:10 2026 +0200 platform/x86/amd/pmc: Avoid logging "(null)" for DMI values commit a0738abd042f7406edd2175a819cf2e66388ed97 upstream. dmi_get_system_info(...) can return NULL. Using that as %s arguments of dev_info() would log "(null)" (as part of a message like '... System Vendor: "(null)", Product Name: "(null)" ...'), which may be confusing for users. Use Elvis operator to print "(Unknown)" instead. Fixes: 428b9fd2dce5 ("platform/x86/amd/pmc: Add delay_suspend module parameter") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606251540.Nr2BtaNu-lkp@intel.com/ Suggested-by: Ilpo Järvinen Signed-off-by: Daniel Gibson Link: https://patch.msgid.link/20260626220210.1761783-2-daniel@gibson.sh Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 744da2443f406e8e4f6afbb40199f81105b86337 Author: Pablo Neira Ayuso Date: Fri Jun 26 13:40:42 2026 +0200 netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master commit bf5355cfdede3e30b30e63a5a74f6bdaafb26082 upstream. If userspace helper policy updates sets maximum number of expectation to zero, cap it to NF_CT_EXPECT_MAX_CNT (255) on updates too. Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 9a7f7b55d7d0fbc4662c981ee6c56e081fa66d58 Author: Gil Portnoy Date: Sun Jul 12 00:00:00 2026 +0000 ksmbd: fix stack buffer overflow in multichannel session-key copy commit 610346149d047a52a92c9a0eb329dd565b8f92c5 upstream. Commit 4b706360ffb7 ("ksmbd: fix multichannel binding and enforce channel limit") moved the binding-path session key out of the session-wide sess->sess_key (CIFS_KEY_SIZE = 40) into a new per-channel buffer, and sized both that buffer and the on-stack copy used during binding with SMB2_NTLMV2_SESSKEY_SIZE (16): struct channel { char sess_key[SMB2_NTLMV2_SESSKEY_SIZE]; /* 16 */ ... }; ntlm_authenticate() / krb5_authenticate(): char channel_key[SMB2_NTLMV2_SESSKEY_SIZE] = {}; /* 16 */ char *auth_key = conn->binding ? channel_key : sess->sess_key; The two writers that fill this destination still bound the copy length against CIFS_KEY_SIZE (40), not against the 16-byte buffer: ksmbd_decode_ntlmssp_auth_blob() (NTLM key exchange): if (sess_key_len > CIFS_KEY_SIZE) /* 40 */ return -EINVAL; arc4_crypt(ctx_arc4, sess_key, (char *)authblob + sess_key_off, sess_key_len); ksmbd_krb5_authenticate(): if (resp->session_key_len > sizeof(sess->sess_key)) /* 40 */ ... memcpy(sess_key, resp->payload, resp->session_key_len); On a binding SESSION_SETUP, auth_key points at the 16-byte channel_key, so a client that supplies an NTLM EncryptedRandomSessionKey of up to 40 bytes (with NTLMSSP_NEGOTIATE_KEY_EXCH), or a Kerberos ticket whose session key is longer than 16 bytes (a normal AES256 key is 32), writes past the 16-byte stack buffer -- up to a 24-byte kernel stack overflow. KASAN reports it as a stack-out-of-bounds write in arc4_crypt() called from ksmbd_decode_ntlmssp_auth_blob(). The destinations must be able to hold the full session key the length checks already permit. Size the per-channel key buffer and the two on-stack channel_key buffers with CIFS_KEY_SIZE, matching sess->sess_key. Fixes: 4b706360ffb7 ("ksmbd: fix multichannel binding and enforce channel limit") Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 59da37fee81a8d76079313348ca13c5bc90dd6ae Author: Junrui Luo Date: Mon Jun 15 23:04:27 2026 +0800 octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF commit 8cdcf3d2caacdee7ddd363705fb4d93b0c1a0915 upstream. rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block. Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB78811656934E713B77DA6CEDAFE62@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9f8e7f59b0c2f466be74bd923726b0f5496c27ad Author: Ankit Garg Date: Tue Jun 16 18:32:08 2026 -0700 gve: fix header buffer corruption with header-split and HW-GRO commit d676c9a73bdcd8237425dbb826f2bd1a25c36e40 upstream. The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing. Cc: stable@vger.kernel.org Fixes: 5e37d8254e7f ("gve: Add header split data path") Signed-off-by: Ankit Garg Reviewed-by: Praveen Kaligineedi Reviewed-by: Jordan Rhee Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260617013208.3781453-1-joshwash@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d8ce67fa6a5e6929f5414e933ff9665176c2bce6 Author: Shitalkumar Gandhi Date: Wed May 20 16:27:50 2026 +0530 ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit commit 6d7f7bcf225b2d566176bf6229dbd1252940cb3c upstream. ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers. Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Cc: stable@vger.kernel.org Signed-off-by: Shitalkumar Gandhi Reviewed-by: Simon Horman Link: https://lore.kernel.org/20260520105750.30144-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 7e3630fbb6aabb844bbf35746dee0bf3894100c7 Author: Shitalkumar Gandhi Date: Tue Apr 21 13:02:59 2026 +0530 ieee802154: ca8210: fix cas_ctl leak on spi_async failure commit e09390e439bd7cca30dd10893b1f64802961667a upstream. ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync(). Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Cc: stable@vger.kernel.org Signed-off-by: Shitalkumar Gandhi Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/20260421073259.2259783-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 2953ec261bcf623f8c0d8132f6367259f1ebc308 Author: Michael Bommarito Date: Wed May 20 10:16:40 2026 -0400 ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation commit a6bfdfcc6711d1d5a92e98644359dedc67c0c858 upstream. The LLSEC ADD/DEL doit handlers under the legacy IEEE802154_NL family consume IEEE802154_ATTR_LLSEC_KEY_BYTES and IEEE802154_ATTR_LLSEC_KEY_USAGE_COMMANDS, both declared in net/ieee802154/nl_policy.c as bare length entries with no .type (defaulting to NLA_UNSPEC). Generic netlink strict validation rejects all NLA_UNSPEC attributes via validate_nla(), so every LLSEC_ADD_KEY, LLSEC_DEL_KEY, LLSEC_ADD_DEV, LLSEC_DEL_DEV, LLSEC_ADD_DEVKEY, LLSEC_DEL_DEVKEY, LLSEC_ADD_SECLEVEL, and LLSEC_DEL_SECLEVEL request fails at the dispatcher with "Unsupported attribute" before reaching the handler. The doit path has been silently dead since strict validation became the default for genl families that do not opt out. The dump path is unaffected because dump requests carry no LLSEC attributes to validate, which is why the LLSEC_LIST_KEY read remained reachable (patch 1/2). Introduce IEEE802154_OP_RELAXED() mirroring IEEE802154_OP() but with .validate = GENL_DONT_VALIDATE_STRICT, and use it for the eight legacy LLSEC mutate ops so admin-driven LLSEC configuration via the legacy interface works again. Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://lore.kernel.org/20260520141640.1149513-3-michael.bommarito@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 6383248058956f2a52d720b1e9f8921099cdae04 Author: Michael Bommarito Date: Wed May 20 10:16:39 2026 -0400 ieee802154: admin-gate legacy LLSEC dump operations commit 9c1e0b6d49471a712511d23fc9d06901561135e8 upstream. In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged users" annotations). Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://lore.kernel.org/20260520141640.1149513-2-michael.bommarito@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit d0c880c9f4051100517040d065caff60e913b659 Author: Haoxiang Li Date: Tue Jun 23 19:43:16 2026 +0800 octeontx2-af: Free BPID bitmap on setup failure commit 36323f54cd323122a1be89ab2c316a6e55a94e30 upstream. nix_setup_bpids() allocates bp->bpids with rvu_alloc_bitmap(), which uses a plain kcalloc(). If any of the following devm_kcalloc() allocations for the BPID mapping arrays fails, the function returns without freeing the bitmap. Free the BPID bitmap before returning from those error paths. Fixes: d6212d2e41a0 ("octeontx2-af: Create BPIDs free pool") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260623114316.2182271-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d4bcc202a3530c856e1cb183384bc9cc8fddab22 Author: Maoyi Xie Date: Fri Jun 12 16:59:38 2026 +0800 net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink commit 2496fa0b7d180b3ad356b514e7ff93bb14e6140a upstream. ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 0bd8762824e7 ("ip6tnl: add x-netns support") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-5-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c38c8b0db3c65b597e7ece317b6cb59de3d15e69 Author: Maoyi Xie Date: Fri Jun 12 16:59:39 2026 +0800 net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink commit f00a50876d2818bd6dc86fa98b3ef360884c53c8 upstream. ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 690afc165bb3 ("net: ip6_gre: fix moving ip6gre between namespaces") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-6-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d49edcc65e0a37cc9b386a94415c5d6670ca8b71 Author: Maoyi Xie Date: Fri Jun 12 16:59:36 2026 +0800 net: ipip: require CAP_NET_ADMIN in the device netns for changelink commit 8211a26324667980a463c069469a818e71207e02 upstream. ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 6c742e714d8c ("ipip: add x-netns support") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-3-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 88b33ee458a6ca5fbef6c53b9dba772da69dab68 Author: Maoyi Xie Date: Fri Jun 12 16:59:37 2026 +0800 net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink commit 95cceadbfd52d7239bd730afdda0655287d77425 upstream. vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 895de9a3488a ("vti4: Enable namespace changing") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-4-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f97e93ebf2f9b8ef3b87f7a9371255e84d151587 Author: Maoyi Xie Date: Fri Jun 12 16:59:40 2026 +0800 net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink commit e2ac3b242c37dff323a964962e43854f4b1a2b79 upstream. vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 61220ab34948 ("vti6: Enable namespace changing") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-7-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 11f68ebc6891d11de5f32b7dee918c5dc18b8de1 Author: Dawei Feng Date: Tue Jun 16 22:24:24 2026 +0800 net: ena: clean up XDP TX queues when regular TX setup fails commit 1bd6676254b4ab6acd44b662b5e92822c036463a upstream. create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed. Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Reviewed-by: Arthur Kiyanovski Tested-by: Arthur Kiyanovski Link: https://patch.msgid.link/20260616142424.4005130-1-dawei.feng@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6fed707239c4c1b4d9ca0ee34100afe4900429c6 Author: Ross Porter Date: Wed Jun 17 18:10:39 2026 +1200 selftests: net: fix file owner for broadcast_ether_dst test commit b8613e9792002add3bf77122868cc06ce142e953 upstream. Ensure the output file is always owned by root (even if tcpdump was compiled with `--with-user`), by passing the `-Z root` argument when invoking it. Cc: stable@vger.kernel.org Reported-by: Edoardo Canepa Closes: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2129815 Fixes: bf59028ea8d4 ("selftests: net: add test for destination in broadcast packets") Suggested-by: Edoardo Canepa Tested-by: Ross Porter Signed-off-by: Ross Porter Link: https://patch.msgid.link/20260617061039.79717-2-ross.porter@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f7f45ceb855d9ba1cba594fb3f383255f7013fad Author: Zihan Xi Date: Sun Jun 14 01:42:39 2026 +0800 net/sched: act_ct: preserve tc_skb_cb across defragmentation commit 9092e15defbe6c7bc241c306093ca9d358a578e7 upstream. tcf_ct_handle_fragments() calls nf_ct_handle_fragments() without saving and restoring skb->cb. The defrag helper clears IPCB/IP6CB, which aliases the tc_skb_cb/qdisc_skb_cb control buffer. Fragmented traffic through act_ct therefore loses qdisc metadata such as pkt_segs and can trigger WARN_ON_ONCE() in qdisc_pkt_segs() when panic_on_warn is enabled. Save and restore the full tc_skb_cb around nf_ct_handle_fragments(), matching the pattern used by ovs_ct_handle_fragments(). Fixes: ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Zihan Xi Signed-off-by: Ren Wei Link: https://patch.msgid.link/510c51217fd7aaf29c6dc298bab8d643fe229b1c.1781358692.git.xizh2024@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 91850f582783098415a334f8bd0a84c87ff15a8c Author: Haoxiang Li Date: Mon Jun 22 12:30:15 2026 +0800 net: ixp4xx_hss: fix duplicate HDLC netdev allocation commit db818b0e8af7bac16860116a19c341a63d6677b4 upstream. ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored in ndev, initialized, and registered with register_hdlc_device(). The second one is stored in port->netdev and later used by the remove path for unregister_hdlc_device() and free_netdev(). This means that the registered netdev is not the same object that is unregistered and freed on remove. It also leaks the first allocation if the second alloc_hdlcdev() call fails, and the first allocation is not checked before ndev is used. Older code allocated the HDLC netdev only once and stored the same object in both the local variable and port->netdev. The buggy conversion split this into two alloc_hdlcdev() calls. A later rename changed the local variable name to ndev, but the underlying mismatch remained. Fix this by allocating the HDLC netdev only once and assigning the same object to port->netdev. Fixes: 99ebe65eb9c0 ("net: ixp4xx_hss: move out assignment in if condition") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260622043015.643637-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0c0a8c7821485f32bdb4923fb22f2dd501a27d8a Author: Haoxiang Li Date: Sun Jun 21 11:17:14 2026 +0800 net: wwan: t7xx: destroy DMA pool on CLDMA late init failure commit 2bd6f26d4ce1e87de4d736b1e8896daf3acf1c0e upstream. t7xx_cldma_late_init() creates md_ctrl->gpd_dmapool before initializing the TX and RX rings. If any ring initialization fails, the error path frees the already initialized rings but leaves the DMA pool allocated. Destroy md_ctrl->gpd_dmapool on the late-init failure path to avoid leaking the DMA pool. Fixes: 39d439047f1d ("net: wwan: t7xx: Add control DMA interface") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260621031714.3605022-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b3763f7e22ecaa7ad79bf44bf41816d488edbcf8 Author: Philippe Schenker Date: Thu Jun 18 11:30:24 2026 +0200 net: ethernet: ti: icssg: guard PA stat lookups commit 27b9daba50609335db6ca81e4cccf50ded21ec76 upstream. icssg_ndo_get_stats64() unconditionally calls emac_get_stat_by_name() with FW PA stat names regardless of whether the PA stats block is present on the hardware. emac_get_stat_by_name() already guards the PA stats lookup with `if (emac->prueth->pa_stats)`; when that pointer is NULL the lookup falls through to netdev_err() and returns -EINVAL. Because ndo_get_stats64 is polled regularly by the networking stack this produces thousands of log entries of the form: icssg-prueth icssg1-eth end0: Invalid stats FW_RX_ERROR A secondary consequence is that the int(-EINVAL) return value is implicitly widened to a near-ULLONG_MAX unsigned value when accumulated into the __u64 fields of rtnl_link_stats64, silently corrupting the rx_errors, rx_dropped and tx_dropped counters reported by `ip -s link`. Every other PA-aware code path in the driver is already guarded with the same `if (emac->prueth->pa_stats)` check. Apply the same guard here. Fixes: 0d15a26b247d ("net: ti: icssg-prueth: Add ICSSG FW Stats") Signed-off-by: Philippe Schenker Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman Cc: danishanwar@ti.com Cc: rogerq@kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260618093037.3448858-1-dev@pschenker.ch Signed-off-by: Jakub Kicinski commit 99ae3248b33df94201915d9c32e7470cdf08cfcd Author: Maoyi Xie Date: Thu Jun 18 15:08:17 2026 +0800 net: sit: require CAP_NET_ADMIN in the device netns for changelink commit 27ccb68e7cccead5d8c611665a45d23032d468b3 upstream. ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers. Fixes: 5e6700b3bf98 ("sit: add support of x-netns") Link: https://lore.kernel.org/netdev/20260612085941.3158249-1-maoyixie.tju@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Nicolas Dichtel Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260618070817.3378283-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f4170f45c251c2c51756efdc5868976369068fe5 Author: Andreas Kemnade Date: Sat Jul 4 10:40:54 2026 +0200 gpios: palmas: add .get_direction() op commit db4a79713ed8e252d5e4edf6eaaa80948b6855a2 upstream. Accessing debug/gpio is quite noisy without a get_direction() implementation. To calm that down add an implementation. Fixes: 3d50a2785271 ("gpio: palmas: Add support for Palmas GPIO") Cc: stable@vger.kernel.org Reviewed-by: Linus Walleij Signed-off-by: Andreas Kemnade Link: https://patch.msgid.link/20260704-palmas-getdirection-v2-1-2fd85fee3832@kemnade.info Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit a60a40c9ba30edd06d3fb4215fdf430ed968728e Author: Sergio Paracuellos Date: Fri Jun 26 08:01:09 2026 +0200 gpio: mt7621: avoid corruption of shared interrupt trigger state commit 1781172526d1092323af443fa03f00e6de560401 upstream. The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Sergio Paracuellos Link: https://patch.msgid.link/20260626060112.2498324-2-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit b90f24527723049af27cd74d668432c7425f956f Author: Paul Louvel Date: Mon Jun 29 16:07:02 2026 +0200 gpio-f7188x: Add support for NCT6126D version B commit 9a6c0b6ea12746d50cf53d59a7e05fd83f974bda upstream. The Nuvoton NCT6126D Super-I/O is available in two hardware revisions. According to the manufacturer datasheet revision 2.4, version A reports chip ID 0xD283, while version B reports chip ID 0xD284. The driver currently only recognizes only the version A ID. Version B only contains hardware fixes unrelated to the GPIO functionality, so it can be supported by simply adding its chip ID without any other driver changes. Fixes: 3002b8642f01 ("gpio-f7188x: fix chip name and pin count on Nuvoton chip") Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Link: https://patch.msgid.link/20260629-gpio-f7188x-nct6126d-version-b-v1-1-a06226c02a2d@bootlin.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 422a0567cd1b7e6d7892ce1ab748119c0015b623 Author: Sergio Paracuellos Date: Fri Jun 26 08:01:11 2026 +0200 gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips commit 0e024f58291dfcb28d98c512002e1a80fad69798 upstream. Function 'mediatek_gpio_bank_probe()' registers three GPIO chips using 'devm_gpiochip_add_data()'. At this point, the chips become live and visible to consumers. However, the IRQ domain isn't allocated and set up until 'mt7621_gpio_irq_setup()' is called after the GPIO chips setup finishes. If a consumer requests a GPIO IRQ concurrently 'mt7621_gpio_to_irq()' can be called and pass a NULL irq domain pointer irq_create_mapping(), that can corrupt the mappings or cause a crash. Fix this possible problem seting up irq domain before GPIO chips setup is performed. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: a46f2e5720f5 ("gpio: mt7621: fix interrupt banks mapping on gpio chips") Signed-off-by: Sergio Paracuellos Link: https://patch.msgid.link/20260626060112.2498324-4-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 628c63f96f4564fa145f602af2d41daf9532201f Author: Runyu Xiao Date: Fri Jun 19 23:24:39 2026 +0800 gpio: tegra: do not call pinctrl for GPIO direction commit d3e91a95b2b0fc6336dbf3ec90d831a1654d2720 upstream. tegra_gpio_direction_input() and tegra_gpio_direction_output() already program the GPIO controller direction registers directly. The additional pinctrl_gpio_direction_input/output() calls do not add a Tegra pinctrl operation, because the Tegra pinmux ops provide GPIO request/free handling but no gpio_set_direction hook. The extra call still enters the pinctrl core and takes pctldev->mutex. Shared GPIO users can call the direction path while holding their per-line spinlock, so this otherwise redundant pinctrl direction call can sleep in an atomic context. This was found by our static analysis tool and then confirmed by manual review of tegra_gpio_probe(), the Tegra GPIO direction callbacks and the Tegra pinctrl ops. The reviewed path has a default non-sleeping struct gpio_chip while the direction callback still enters the pinctrl mutex path. A directed runtime validation kept the same non-sleeping chip registration and drove: gpio_shared_proxy_direction_output() gpiod_direction_output_raw_commit() tegra_gpio_direction_output() pinctrl_gpio_direction_output() Lockdep reported a sleep-in-atomic warning with the shared GPIO spinlock held and pinctrl_get_device_gpio_range() plus tegra_gpio_direction_output() on the stack. Do not mark the whole chip as can_sleep to paper over this: can_sleep describes whether get()/set() may sleep, and Tegra value access is MMIO. Remove the redundant pinctrl direction calls and keep pinctrl involvement in the existing request/free path. Fixes: 11da90541283 ("gpio: tegra: Fix offset of pinctrl calls") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260619152439.1239561-1-runyu.xiao@seu.edu.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit e187f6fbc8d621a707020e2d7a9ce23472460ee2 Author: Sergio Paracuellos Date: Fri Jun 26 08:01:10 2026 +0200 gpio: mt7621: more robust management of IRQ domain teardown commit 839738536adabae1a7e98ed3fc332ce9cc991d27 upstream. The driver uses devm_gpiochip_add_data() to register the GPIO chips which means the devres subsystem will unregister them only after the function 'mt7621_gpio_remove()' returns. During the window between domain destruction and devres unregistering the GPIO chips, the chips are still fully active. If a consumer or userspace invokes gpiod_to_irq() during this window, 'mt7621_gpio_to_irq()' can dereference the already-freed irq domain pointer. Thus, manage the IRQ domain teardown using 'devm_add_action_or_reset()' to guarantee it is destroyed strictly after the GPIO chips are removed. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: a46f2e5720f5 ("gpio: mt7621: fix interrupt banks mapping on gpio chips") Signed-off-by: Sergio Paracuellos Link: https://patch.msgid.link/20260626060112.2498324-3-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit bc650dd5ce6434286b96e2b26a41af81f679cc7c Author: Dexuan Cui Date: Wed Jul 1 21:12:37 2026 -0700 net: mana: Sync page pool RX frags for CPU commit c72a0f09c57f92113df69f9b902d11c9e4b132f5 upstream. MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack. Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang Signed-off-by: Dexuan Cui Link: https://patch.msgid.link/20260702041237.617719-3-decui@microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 282c5214ca4eb3799158c76782646e86d2945d1b Author: Dexuan Cui Date: Wed Jul 1 21:12:36 2026 -0700 net: mana: Validate the packet length reported by the NIC commit 2e2a83b4998af4384e677d3b2ac08565274279bf upstream. Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted. Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang Signed-off-by: Dexuan Cui Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Link: https://patch.msgid.link/20260702041237.617719-2-decui@microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 631d53102da9f469c96b882b770336bec095b833 Author: Bradley Morgan Date: Fri Jun 19 16:37:18 2026 +0000 cpu: hotplug: Bound hotplug states sysfs output commit 86f436567f2516a0083b210bedc933544826a2c3 upstream. states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded. Fixes: 98f8cdce1db5 ("cpu/hotplug: Add sysfs state interface") Signed-off-by: Bradley Morgan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260619163719.12103-2-include@grrlz.net Signed-off-by: Greg Kroah-Hartman commit 9f7dc355f62c011e4afe8286cf71130d4bfb9d80 Author: Bradley Morgan Date: Fri Jun 19 16:37:17 2026 +0000 cpu: hotplug: Preserve per instance callback errors commit 673db10729fb121ea1b16fe57791a0cb9eac1eb5 upstream. cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error. Fixes: 724a86881d03 ("smp/hotplug: Callback vs state-machine consistency") Signed-off-by: Bradley Morgan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260619163719.12103-1-include@grrlz.net Signed-off-by: Greg Kroah-Hartman commit f563358661eab1be3ebf62f6f9237092794f83dc Author: Cao Ruichuang Date: Tue Apr 7 18:26:13 2026 +0800 selftests/ftrace: Drop invalid top-level local in test_ownership commit 808c447df2fe234eb7d9e08ecf53159d291c104c upstream. test_ownership.tc is sourced by ftracetest under /bin/sh. The script currently declares mount_point with local at file scope, which makes /bin/sh abort with "local: not in a function" before the test can reach the eventfs ownership checks. Replace the top-level local declaration with a normal shell variable so kernels that support the gid= tracefs mount option can run the test at all. Link: https://lore.kernel.org/r/20260407102613.81419-1-create0818@163.com Fixes: 8b55572e51805 ("tracing/selftests: Add tracefs mount options test") Signed-off-by: Cao Ruichuang Reviewed-by: Steven Rostedt (Google) Acked-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 571e1f10b5996ba3e4dc63ea77de4aa309c384ce Author: Zhan Xusheng Date: Tue Jun 16 19:20:17 2026 +0800 posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() commit 26aff38fefb1d6cd87e22525f41cc8f1aa61b24f upstream. update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected. Fixes: 858cf3a8c599 ("timers/itimer: Convert internal cputime_t units to nsec") Signed-off-by: Zhan Xusheng Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616112017.1681372-1-zhanxusheng@xiaomi.com Signed-off-by: Greg Kroah-Hartman commit 83f9fb561c1c3917e19f95523dd933c7d30291aa Author: Thomas Gleixner Date: Fri Jun 19 14:52:08 2026 +0200 locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() commit 89038cc87d80c77e7aa6f42a64b2573b74af339f upstream. rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1 T2 spin_lock(&p->lock); rcu_read_lock(); invalidate(p); p = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL); if (!p) return; spin_unlock(&p->lock); spin_lock(&p->lock) lock(&lock->lock); rcu_read_lock(); kfree_rcu(p); rcu_read_unlock(); .... spin_unlock(&p->lock) rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); UAF -> rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled. Fixes: 0f383b6dc96e ("locking/spinlock: Provide RT variant") Reported-by: syzbot+000c800a02097aaa10ed@syzkaller.appspotmail.com Decoded-by: Jann Horn Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Acked-by: Al Viro Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87jyrud75z.ffs@fw13 Signed-off-by: Greg Kroah-Hartman commit bcf7968cb97ce4312588042cf2712f04caff6d8f Author: Maoyi Xie Date: Mon Jun 22 15:53:38 2026 +0800 wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() commit aa6dcd5c8dd9ba1d7d0f60093bcda41c0d6d438d upstream. lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 ("wifi: libertas: fix use-after-free in lbs_free_adapter()") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed. Fixes: 06b16ae53192 ("libertas_tf: main.c, data paths and mac80211 handlers") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/178211481807.2212567.8773346114561900100@maoyixie.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 05b24f68f78ff3a1ef7f015f7327b35886b741f6 Author: Michael Bommarito Date: Tue Jul 7 12:59:11 2026 -0400 tracing/user_events: Fix use-after-free in user_event_mm_dup() commit 50fd6dd755c6e48a38af2fa4621167eea56829c2 upstream. user_event_mm_dup() walks the parent mm's enabler list locklessly under rcu_read_lock() during fork() (from copy_process()); it does not take event_mutex: rcu_read_lock(); list_for_each_entry_rcu(enabler, &old_mm->enablers, mm_enablers_link) enabler->event = user_event_get(orig->event); user_event_enabler_destroy() removes an enabler from that list with list_del_rcu() and then, without waiting for a grace period, drops the enabler's user_event reference with user_event_put() and frees the enabler with kfree(). A reader that loaded the enabler before the list_del_rcu() can still be walking it, which leads to two use-after-frees: - kfree(enabler) frees the enabler while that reader dereferences enabler->event. - user_event_put() may drop the last reference to the user_event, which is then freed (via delayed_destroy_user_event() on a work queue), while the same reader does user_event_get(orig->event) on it. Both are reachable by an unprivileged task that can open user_events_data: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in user_event_mm_dup() during clone(), with a "refcount_t: addition on 0" warning when the user_event is freed. The enabler use-after-free was found first; the user_event one was reported by XIAO WU, and the earlier enabler-only fix did not address it. Defer both the user_event_put() and the kfree(enabler) to a work item queued with queue_rcu_work(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because user_event_put() takes event_mutex on the last reference, so a work queue is used rather than call_rcu(). The now-unlocked put lets the locked argument of user_event_enabler_destroy() be removed; all callers are updated. Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260707165912.2560537-2-michael.bommarito@gmail.com Reported-by: XIAO WU Closes: https://lore.kernel.org/all/tencent_89647CE40DC452B891C65C94D1B271DE8E07@qq.com/ Suggested-by: Beau Belgrave Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 088873af13590ebde10de2ade847f57a05ec61c6 Author: Doruk Tan Ozturk Date: Sun Jun 28 00:30:59 2026 +0200 net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete commit de74d8fd10291763d97b218f09adcc7513c975e4 upstream. When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory. Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken. mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath. Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260627223059.29917-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 618cf6b139503ec18ef93ffd663396aaf99b763a Author: Guangshuo Li Date: Fri Jun 12 11:27:56 2026 +0800 mmc: vub300: fix use-after-free on probe failure commit a3b5f242997a3be7404112fd48784881560aea57 upstream. The vub300 driver lifetime-manages its controller state using vub300->kref, with vub300_delete() freeing the mmc host when the last reference is dropped. The probe error path after the inactivity timer has been armed still bypasses that lifetime rule, however, and falls through to mmc_free_host() directly if mmc_add_host() fails. The race window is between arming the inactivity timer and reaching the probe error unwind after mmc_add_host() fails: probe thread timer/workqueue ------------ --------------- kref_init(&vub300->kref) ref = 1 kref_get(&vub300->kref) ref = 2, timer ref add_timer(inactivity_timer) fires after one second | | race window |<----------------------------------------------------> | mmc_add_host(mmc) inactivity timer fires vub300_queue_dead_work() kref_get() ref = 3 queue_work(deadwork) mmc_add_host() fails timer_delete_sync() mmc_free_host(mmc) frees vub300 deadwork runs use-after-free The inactivity timeout is one second, so this would require mmc_add_host() to both fail and take more than one second to do so. This is unlikely to happen in practice, but the error path is still wrong. timer_delete_sync() only waits for the timer callback itself. It does not flush deadwork that the callback may already have queued. As a result, queued deadwork can still hold a kref while the probe error path directly frees the backing mmc host, including the vub300 storage. Fix this by using the same lifetime mechanism as disconnect. Clear vub300->interface so that the timer callback and any queued deadwork return early and drop their references, then drop the initial probe reference and return without falling through to err_free_host. Fixes: 0613ad2401f8 ("mmc: vub300: fix return value check of mmc_add_host()") Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f4cf878dcc4f6f02e7a25294bfaed4361264995e Author: Dmitry Torokhov Date: Fri May 22 10:25:11 2026 -0700 Input: ims-pcu - fix type confusion in CDC union descriptor parsing commit ca459e237bc49567649c56bc72e4c602fb92fd67 upstream. The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 025955847e1500ced4719ac178beff6a3b2f0e3c Author: Dmitry Torokhov Date: Fri May 22 10:29:04 2026 -0700 Input: ims-pcu - fix race condition in reset_device sysfs callback commit 411b8c4b274737c3bf08e1e025801161603cfffc upstream. The ims_pcu_reset_device() sysfs callback calls ims_pcu_execute_command() without acquiring pcu->cmd_mutex. This can lead to data races and corruption of the shared command buffer if triggered concurrently with other commands. Acquire pcu->cmd_mutex before calling ims_pcu_execute_command(). Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bbbe31486cf2d12177462e4a814244c2597c9849 Author: Dmitry Torokhov Date: Fri May 22 21:42:39 2026 -0700 Input: ims-pcu - fix potential infinite loop in CDC union descriptor parsing commit d4579af29e67ca8722db0a1194227f8015c8981d upstream. The driver parses CDC union descriptors in ims_pcu_get_cdc_union_desc() by iterating through the extra descriptor data. However, it does not verify that the bLength of each descriptor is at least 2. A malicious device could provide a descriptor with bLength = 0, leading to an infinite loop in the driver. Add a check to ensure bLength is at least 2 before proceeding with parsing. Fixes: 628329d52474 (Input: add IMS Passenger Control Unit driver) Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f97bfc1a0766802a99167b3dc62d1ee7dca929fe Author: Dmitry Torokhov Date: Fri May 22 10:30:21 2026 -0700 Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging commit 403b0a6970b1084bb27907c0f8225801fdd0fe1d upstream. The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e555f00621bdeeaaafd0da4e876fe249e32ebab3 Author: Dmitry Torokhov Date: Fri May 22 10:29:41 2026 -0700 Input: ims-pcu - fix logic error in packet reset commit 2c9b85a14abb4811e8d4773ccd13559e59792efb upstream. ims_pcu_reset_packet() incorrectly sets have_stx to true, which implies that the start-of-packet delimiter has already been received. This causes the protocol parser to skip waiting for the next STX byte and potentially process garbage data. Correctly set have_stx to false when resetting the packet state. Fixes: 875115b82c29 ("Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 47a9889a9325b87698b6d6eaf3187a9af6e4773d Author: Dmitry Torokhov Date: Fri May 22 10:25:31 2026 -0700 Input: ims-pcu - fix firmware leak in async update commit d48795b5cd6828d36b707e8d62fc9e5c90e004ab upstream. The firmware object was not being released if validation failed. Use __free(firmware) to ensure the firmware is always released. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 40693fcc88bc75731d8884c2bcb69edf7225bdee Author: Dmitry Torokhov Date: Fri May 22 10:30:44 2026 -0700 Input: ims-pcu - fix DMA mapping violation in line setup commit 8adf4289d945e8990e4336436a97da71d21d2cae upstream. In ims_pcu_line_setup(), the driver uses pcu->cmd_buf as a transfer buffer for usb_control_msg(). However, pcu->cmd_buf is embedded in the struct ims_pcu allocation, which violates DMA mapping rules regarding cacheline alignment. Use a heap-allocated buffer for the line coding data instead. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f3c63aecca90be42b66cdc66de7c4a6104104d17 Author: Dmitry Torokhov Date: Fri May 22 10:40:54 2026 -0700 Input: ims-pcu - add response length checks commit 48c9d92fd4ee3a8f5d2cb46c802a0eff8e67c79c upstream. The driver processes response data from device buffers without verifying that the device actually sent enough data. This can lead to out-of-bounds reads or processing stale data. Add checks for the expected response length before accessing the buffers. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit cbfa059dfb48b9aa322e34fd44a093d9ca29ad7e Author: Dmitry Torokhov Date: Fri May 22 10:29:26 2026 -0700 Input: ims-pcu - validate control endpoint type commit baf56975806534268e24acf9a8abb1c447ce11e9 upstream. The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8c3095c4329172cb4ad7997dbdf050441546299f Author: Dmitry Torokhov Date: Fri May 22 10:22:55 2026 -0700 Input: ims-pcu - release data interface on disconnect commit 441c510a649c8ddce38aa0311334ed8bb546b36c upstream. During probe the driver claims the data interface, but it never releases it. Release it in disconnect to avoid leaving it permanently claimed. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 73e6687be0c1c323a8ec5b733f29440a93e08ff2 Author: Dmitry Torokhov Date: Sun May 31 21:42:35 2026 -0700 Input: ims-pcu - only expose sysfs attributes on control interface commit 001428ea4d2c371107cb984108e266adf99f1f1e upstream. When the driver was converted to use the driver core to instantiate device attributes (via .dev_groups in the usb_driver structure), the attributes started appearing on all interfaces bound to the driver. Since the ims-pcu driver manually claims the secondary data interface during probe, the driver core automatically creates the sysfs attributes for that interface as well. However, the driver only supports these attributes on the primary control interface. Data interfaces lack the necessary descriptors and internal state to handle these requests, and accessing them can lead to unexpected behavior or crashes. Fix this by updating the is_visible() callbacks for both the main and OFN attribute groups to verify that the interface being accessed is indeed the control interface. Fixes: 204d18a7a0c6 ("Input: ims-pcu - use driver core to instantiate device attributes") Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ahp23lj4_vXIeUBl@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bf0b58ba489d0bdaa18c7dd8beeaeb954dd7dbb7 Author: Dmitry Torokhov Date: Fri May 22 10:24:47 2026 -0700 Input: ims-pcu - fix use-after-free and double-free in disconnect commit 462a999917755a3bf77448dfd64307963cf0a9f0 upstream. ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7d330a1d663381579b9d5dafa642b1b3158a0ce2 Author: Tony Luck Date: Mon Jul 6 15:46:22 2026 -0700 fs/resctrl: Fix use-after-free during unmount commit 52fce648607e0d6a76eeb443d78708c49df1c554 upstream. During unmount or failure teardown all mon_data structures that contain monitoring event file private data are freed after which kernfs nodes are removed. However, the RDT_DELETED flag is never set for the statically allocated default resource group. A concurrent reader of an event file associated with the default resource group may, after dropping kernfs active protection, block on rdtgroup_mutex while unmount proceeds to free the file private data and destroy the kernfs node without waiting for the reader. When the mutex is released, the reader wakes up, observes that RDT_DELETED is not set for the default group, and dereferences the already-freed file private data. The scenario can be depicted as follows: CPU0 CPU1 /* * Default resource group's * monitoring data accessible via * kernfs file with kernfs_node::priv * pointing to a struct mon_data. * User opens the file for reading. */ rdtgroup_mondata_show() /* arch encounters fatal error */ rdtgroup_kn_lock_live() resctrl_exit() atomic_inc(&rdtgroup_default.waitcount) cpus_read_lock() kernfs_break_active_protection(kn) mutex_lock(&rdtgroup_mutex) cpus_read_lock() resctrl_fs_teardown() mutex_lock(&rdtgroup_mutex) rmdir_all_sub() mon_put_kn_priv() /* Delete all mon_data structures */ rdtgroup_destroy_root() kernfs_destroy_root() rdtgroup_default.kn = NULL mutex_unlock(&rdtgroup_mutex) /* * rdtgroup_default.flags is empty so * rdtgroup_kn_lock_live() returns * &rdtgroup_default */ md = of->kn->priv; /* md points to freed mon_data */ Set RDT_DELETED for the default group unconditionally since the flag does not lead to the freeing of this statically allocated group. Do not allow a new resctrl mount if there are any waiters on default group of previous mount. A new mount will re-initialize the default group that would appear to waiters from previous mount as though the default group is accessible causing them to access the mon_data structures from the previous mount that have been removed. Fixes: 2a6566038544 ("x86/resctrl: Expand the width of domid by replacing mon_data_bits") Closes: https://sashiko.dev/#/patchset/20260508182143.14592-1-tony.luck%40intel.com?part=2 [1] Reported-by: Sashiko Signed-off-by: Tony Luck Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Chen Yu Cc: Link: https://patch.msgid.link/49a2ca3ca688f27e1a646cf90e1dc69287021127.1783377598.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman commit 94cbfed191248dc88c23fc881119bb399486ddfd Author: Haoxiang Li Date: Mon Jun 22 15:58:44 2026 +0800 scsi: elx: efct: Fix I/O leak on unsupported additional CDB commit 9cb2d5291dbfe7bed565ead3337047dee9ed1064 upstream. efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path. Fixes: f45ae6aac0a0 ("scsi: elx: efct: Unsolicited FC frame processing routines") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Daniel Wagner Link: https://patch.msgid.link/20260622075844.832871-1-haoxiang_li2024@163.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 747eaead2db298abfda2aa505f6d03775b40fe5f Author: WenTao Liang Date: Thu Jun 11 13:30:37 2026 +0800 scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() commit 2c007acf7b31c39c08ce4959451ad00b19be4c1f upstream. When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below. Cc: stable@vger.kernel.org Fixes: 63de51327a64 ("scsi: elx: efct: Hardware I/O and SGL initialization") Signed-off-by: WenTao Liang Reviewed-by: Daniel Wagner Link: https://patch.msgid.link/20260611053037.63756-1-vulab@iscas.ac.cn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ef2ee18fec92088c7d8877baf7674e89389ccd66 Author: Bryam Vargas Date: Wed Jun 10 04:22:48 2026 +0000 scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE commit fda6a1f3c3d7047b5ce5654487649c2daa738bfc upstream. core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing "if (buf) transport_kunmap_data_sg(cmd)" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged. Fixes: 4949314c7283 ("target: Allow control CDBs with data > 1 page") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: John Garry Reviewed-by: David Disseldorp Link: https://patch.msgid.link/20260610042245.35473-1-hexlabsecurity@proton.me Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 555a89846ed888d7401b3f7200934c0fbedcbb46 Author: Bryam Vargas Date: Thu Jun 11 13:42:26 2026 -0500 scsi: target: Bound PR-OUT TransportID parsing to the received buffer commit d04a179085c262c9ed577d0a4cbc6482ff1fd9a3 upstream. core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the ",i,0x" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded "%s"). An initiator can submit a TransportID whose iSCSI name contains neither a ",i,0x" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded "%s" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose ",i,0x" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor. Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: John Garry Reviewed-by: David Disseldorp Link: https://patch.msgid.link/20260611-b4-disp-9f20739e-v6-1-f6630e2aae44@proton.me Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1e97c404e44991fb087c38ccd7414f2d326f9b74 Author: Michael Bommarito Date: Thu Jun 11 08:30:45 2026 -0400 scsi: xen: scsiback: Free unsubmitted command instead of double-putting it commit ca978f8a93d4d36841839bf2847d29b88c2591d6 upstream. scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it ("refcount_t: underflow; use-after-free") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot. Fixes: 2dbcdf33dbf6 ("xen-scsiback: Convert to percpu_ida tag allocation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20260611123046.2323342-2-michael.bommarito@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1357fb32d42ad8da193e6da285f09e6452feabda Author: Michael Bommarito Date: Thu Jun 11 08:30:46 2026 -0400 scsi: xen: scsiback: Free the command tag on the TMR submit-failure path commit 66aefc277ebb796ec285d550305535dc3fc0179f upstream. scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too. Fixes: 2dbcdf33dbf6 ("xen-scsiback: Convert to percpu_ida tag allocation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20260611123046.2323342-3-michael.bommarito@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3cbabbf1722ebac97408cc34534fc6794a6179e8 Author: Xu Rao Date: Tue Jul 7 11:08:45 2026 +0800 scsi: sg: Report request-table problems when any status is set commit 1d3a742afeb761eaead774691bde1ced699e9a5d upstream. SG_GET_REQUEST_TABLE reports per-request diagnostic state through sg_req_info::problem. The field is meant to indicate whether there is an error to report for a completed request. sg_fill_request_table() currently combines masked_status, host_status and driver_status with bitwise AND. This only reports a problem when all three status fields are non-zero at the same time. A normal target check condition, for example, has masked_status set while host_status and driver_status may both be zero, so the request is incorrectly reported as clean. Use the same condition as sg_new_read(), which sets SG_INFO_CHECK when any of the three status fields is non-zero. Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/54B60C19F7DB8889+20260707030845.970018-1-raoxu@uniontech.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0ce5a37f7ddf2fc12210e8700350274da79fbb3a Author: Abdun Nihaal Date: Tue Jul 7 12:23:02 2026 +0530 scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup() commit 1bd28625e25be549ee7c47532e7c3ef91c682410 upstream. The memory allocated for mboxq using mempool_alloc() is not freed in some of the early exit error paths. Fix that by moving the mempool_free() call to an earlier point after last use. Fixes: d79c9e9d4b3d ("scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Justin Tee Link: https://patch.msgid.link/20260707065304.949135-1-nihaal@cse.iitm.ac.in Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 782e1bf48672be44265c48e14602696c3c8ed904 Author: Haoxiang Li Date: Tue Jun 23 00:00:28 2026 +0800 scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path commit e166bafc483e927150cb9b5f286c9191ea0df84e upstream. If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning. Fixes: c5dfd106414f ("scsi: hpsa: correct device resets") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Acked-by: Don Brace Link: https://patch.msgid.link/20260622160028.1240496-1-haoxiang_li2024@163.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6920e62be4c969a68ce4ebc59da68c6cbc9512e5 Author: Jhonraushan Date: Wed Jul 15 13:12:06 2026 +0530 accel/ivpu: Reject firmware log with size smaller than header commit ddb44baed257560f192b145ed36cf8c0a412de47 upstream. fw_log_from_bo() validates the tracing buffer header_size and that the log fits within the BO, but never checks that log->size is at least log->header_size. fw_log_print_buffer() then computes: u32 data_size = log->size - log->header_size; which underflows to a near-U32_MAX value when firmware reports a log whose size is smaller than its header. That huge data_size defeats the log_start/log_end bounds clamps added by commit dd1311bcf0e6 ("accel/ivpu: Add bounds checks for firmware log indices"), so fw_log_print_lines() reads far past the small real data region of the BO. A size of 0 also makes fw_log_from_bo() advance the offset by 0, causing the callers to loop forever on the same header. Reject logs whose size is smaller than the header (which also rejects size == 0). Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support") Cc: stable@vger.kernel.org Signed-off-by: Jhonraushan Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260715074206.867712-1-raushan.jhon@gmail.com Signed-off-by: Greg Kroah-Hartman commit 216e43d93dd49ec253052741aa476e51a8c54cd8 Author: Shuvam Pandey Date: Tue Jun 16 02:03:00 2026 +0545 accel/amdxdna: Use caller client for debug BO sync commit 7caf2a2351d4053075670ff3e26a6815da0a9e1e upstream. amdxdna_drm_sync_bo_ioctl() looks up args->handle in the ioctl caller's drm_file. For SYNC_DIRECT_FROM_DEVICE, it then calls amdxdna_hwctx_sync_debug_bo(), but passes abo->client. amdxdna_hwctx_sync_debug_bo() uses the passed client both as the handle namespace for debug_bo_hdl and as the owner of the hardware context xarray. Those must match the file that supplied args->handle. The BO's stored client pointer is object state, not the ioctl context. Pass filp->driver_priv instead, matching the original handle lookup. Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Shuvam Pandey Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/178155468039.81818.12173237984867749651@gmail.com Signed-off-by: Greg Kroah-Hartman commit fff6509d976f6fae423a5236391ccdbd7e0e9f06 Author: Doruk Tan Ozturk Date: Mon Jul 13 19:30:28 2026 +0200 accel/amdxdna: reject user command submission without a command BO commit 261c1fe3327ad24508f54552c6366e3e4db82c15 upstream. amdxdna_drm_submit_execbuf() passes the user-supplied command BO handle straight into amdxdna_cmd_submit() with drv_cmd == NULL. When the handle is AMDXDNA_INVALID_BO_HANDLE (0), the block that fetches job->cmd_bo is skipped, leaving it NULL, and no check rejects it on the user path (the !job->cmd_bo guard lives inside the != INVALID branch). The job is then armed and pushed to the DRM scheduler. aie2_sched_job_run() takes the drv_cmd == NULL path and calls amdxdna_cmd_set_state(job->cmd_bo) -> amdxdna_gem_vmap(NULL) -> to_gobj(NULL)->dev, a NULL pointer dereference in the drm_sched worker. A process with access to the accel node on a system with a probed AMD NPU can trigger a kernel oops with a single AMDXDNA_EXEC_CMD ioctl (cmd_handles = 0). Only internal driver commands (SYNC_DEBUG_BO / ATTACH_DEBUG_BO) legitimately pass AMDXDNA_INVALID_BO_HANDLE, and they always set drv_cmd. Reject the invalid handle for user submissions (drv_cmd == NULL) at the submit choke point so every user path is covered. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Cc: stable@vger.kernel.org Found by 0sec automated security-research tooling (https://0sec.ai). Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260713173030.87541-2-doruk@0sec.ai Signed-off-by: Greg Kroah-Hartman commit f7d08603c87bae19ca3e424da5ab6d0aee81886e Author: Doruk Tan Ozturk Date: Mon Jul 13 19:30:29 2026 +0200 accel/amdxdna: reject command submission on devices without a submit op commit 38953513d7313992676d4136cd425cdb70c6278e upstream. amdxdna_cmd_submit() calls xdna->dev_info->ops->cmd_submit() unconditionally, but only aie2_dev_ops defines that callback. aie4_vf_ops (the AIE4 SR-IOV virtual function) does not, so a user AMDXDNA_EXEC_CMD ioctl on an AIE4 device reaches a NULL function-pointer call and oopses the kernel. AIE4 submits work through a mapped user queue and doorbell, not this ioctl path. Reject the submission early with -EOPNOTSUPP when the device provides no cmd_submit op, so the shared EXEC ioctl is a clean no-op on such devices. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Cc: stable@vger.kernel.org Found by 0sec automated security-research tooling (https://0sec.ai). Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260713173030.87541-3-doruk@0sec.ai Signed-off-by: Greg Kroah-Hartman commit 5da885c39baa70f570a8be35a78e85a351f33918 Author: Wentao Liang Date: Thu Jun 25 19:32:39 2026 +0800 accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap() commit 63bbf9ac5dde2ba85e7b39d0a0b7d540e6252ba4 upstream. When vm_insert_pages() fails, the error path calls vma->vm_ops->close(vma) which internally calls drm_gem_vm_close() → drm_gem_object_put(), releasing the GEM object reference acquired at the start of the function. However, the close_vma label then falls through to put_obj, which calls drm_gem_object_put() a second time on the same object. If the first put releases the last reference, the object is freed and the second put accesses freed memory, causing a use-after-free. Fix by returning directly from close_vma instead of falling through to put_obj, since the close handler already performs all necessary cleanup including the object put. Cc: stable@vger.kernel.org Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Signed-off-by: Wentao Liang Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260625113239.49764-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 15ecfdf0ef6f6d874d0a26690d300857b39ebfd0 Author: Philipp Stanner Date: Mon Jun 29 09:56:37 2026 +0200 dma-buf: dma-fence: Fix potential NULL pointer dereference commit 035219a760edb35ae9a9e96beba7f122e26a997b upstream. The commit mentioned in the fixes tag below introduced a mechanism through which fence producers can fully decouple from fence consumers. This, desirable, mechanism is based on the fence's signaled-bit as the "decoupling point". A sophisticated interaction between RCU and atomic instructions attempts to ensure that fence consumers can still interact with fence producers through the dma_fence_ops (callback pointers into the producer). This is the desired behavior: to check for decoupling, the signaled-bit is first checked. If it's not yet signaled, RCU ensures that the ops pointer cannot yet be NULL. Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit, and then sets the ops pointer to NULL. Readers first load the ops pointer, and then check through the signaled-bit whether the pointer can legally be accessed. These set and load operations could occur out of order on weakly ordered platforms. This problem can be solved very elegantly by using the ops pointer itself as the synchronization point. The pointer is either NULL, or cannot become NULL while it is being used thanks to RCU. Replace the signaled-bit check in dma_fence_timeline_name() and dma_fence_driver_name(). Cc: stable@vger.kernel.org Fixes: f4cc3ab824d6 ("dma-buf: protected fence ops by RCU v8") Signed-off-by: Philipp Stanner Reviewed-by: Boris Brezillon Reviewed-by: Christian König Reviewed-by: Danilo Krummrich Link: https://lore.kernel.org/r/20260629075636.2513214-2-phasta@kernel.org Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 562d5e6f9b994058e3b72536f5a1fd461a30bc16 Author: André Draszik Date: Thu Jun 18 13:00:39 2026 +0100 dma-fence: use correct callback in dma_fence_timeline_name() commit 032a6f6ce21fc701468fd15403d2f53a30107f5b upstream. dma_fence_timeline_name() is a wrapper around dma_fence_ops::get_timeline_name(). Since the blamed commit below, it calls an incorrect callback. Update it to restore functionality by calling the intended callback. Fixes: 62918542b7bf ("dma-fence: Fix sparse warnings due __rcu annotations") Cc: # v7.1+ [tursulin: added cc stable] Signed-off-by: André Draszik Reviewed-by: Philipp Stanner Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix-v1-1-801f29c9853d@linaro.org Signed-off-by: Greg Kroah-Hartman commit e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051 Author: Baineng Shou Date: Mon Jun 29 11:13:46 2026 +0800 dma-fence: Make dma_fence_dedup_array() robust against 0-count input commit 77a9298741f8f9e8b963c977f5582ab21c6d3427 upstream. dma_fence_dedup_array() returns 1 when called with num_fences == 0: the for-loop body never executes, j stays at 0, and the final `return ++j` yields 1. This contradicts both the kernel-doc ("Return: Number of unique fences remaining in the array") and the natural expectation that 0 input gives 0 output. The caller __dma_fence_unwrap_merge() bails out via the `if (count == 0 || count == 1)` fast path and so is save. But amdgpu_userq_wait_*() could reach the dedup call with a zero local count and dereference an uninitialized fence slot in the array. Make the contract match the documentation by returning 0 early. This also skips an unnecessary sort() call on an empty array. Cc: stable@vger.kernel.org Signed-off-by: Baineng Shou Reviewed-by: Christian König Fixes: 575ec9b0c2f1 ("dma-fence: Add helper to sort and deduplicate dma_fence arrays") Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260629031346.3875683-1-shoubaineng@gmail.com Signed-off-by: Greg Kroah-Hartman commit 752e214b2c6f15b40b0d873a2ce27733ce0884c6 Author: Mikulas Patocka Date: Thu Jul 9 21:37:38 2026 +0200 dm-verity: make error counter atomic commit 8ec4d9c5a5cf4b61fc087f871465b1f79b393325 upstream. The error counter "v->corrupted_errs" was not atomic, thus it could be subject to race conditions. The call to dm_audit_log_target("max-corrupted-errors") may be skipped due to the races. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Fixes: 65ff5b7ddf05 ("dm verity: add error handling modes for corrupted blocks") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e96df7fdbec9d9a8797298b62854c662f08d318b Author: Mikulas Patocka Date: Thu Jul 9 21:36:01 2026 +0200 dm-verity: increase sprintf buffer size commit 88dd117c92a142253fb7a17e791773902b3babc6 upstream. The prefix "DM_VERITY_ERR_BLOCK_NR" is 22 chars. Add '=', one digit for type, ',', up to 20 digits for a u64 block number, and a NUL terminator: that's 46 bytes. The buffer is 42 bytes. For block numbers >= 16 decimal digits (devices larger than ~16 EB with 4K blocks), snprintf silently truncates the uevent environment variable. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Fixes: 65ff5b7ddf05 ("dm verity: add error handling modes for corrupted blocks") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 81f41d989a32458ff3512f6b05458eaf8926579c Author: Mikulas Patocka Date: Thu Jul 9 21:35:06 2026 +0200 dm-verity: fix a possible NULL pointer dereference commit e72b793ae440f6900fb17a4b8518c707b5cd3e17 upstream. Fix a possible NULL pointer dereference dm_verity_loadpin_is_bdev_trusted if the device has no table. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Fixes: b6c1c5745ccc ("dm: Add verity helpers for LoadPin") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 414650265267ac2b5a8d5c1e406703bd3ced81e6 Author: Mikulas Patocka Date: Thu Jul 9 21:33:16 2026 +0200 dm-verity: avoid double increment of &use_bh_wq_enabled commit 72e9ec2fe32b00994f41719cf77423fca67d48b2 upstream. verity_parse_opt_args is called twice, first with the only_modifier_opts, first with only_modifier_opts == true and then with only_modifier_opts == false. Thus, the static branch &use_bh_wq_enabled was incremented twice and the destructor verity_dtr would only decrement it once. Fix tihs bug by only incrementing it on the first call, on the second call, when v->use_bh_wq is true, do nothing. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Cc: stable@vger.kernel.org Fixes: df326e7a0699 ("dm verity: allow optional args to alter primary args handling") Signed-off-by: Greg Kroah-Hartman commit f7990c2b0f08b8841fcd2652d1d7002f5994a7a7 Author: Mikulas Patocka Date: Wed Jul 1 18:13:50 2026 +0200 dm-verity: fix buffer overflow in FEC calculation commit 31d6e6c0ba8d5a7bd59660035a089307100c5e8e upstream. There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) fio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Cc: stable@vger.kernel.org Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Reviewed-by: Sami Tolvanen Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 829476c06496aab018f14127c055adb164d1a750 Author: Mikulas Patocka Date: Thu Jul 9 21:24:09 2026 +0200 dm-integrity: don't increment hash_offset twice commit edf025f083854f80032b73a1aad69a3c90db236f upstream. hash_offset is already incremented in the loop "for (i = 0; i < to_copy; i++, ts--)". Do not increment it again. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Fixes: 84597a44a9d8 ("dm-integrity: dm integrity: add optional discard support") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3d1afaa074622859678b1a1e7c1b9c0af74c89b0 Author: Mikulas Patocka Date: Thu Jul 9 21:25:39 2026 +0200 dm-integrity: fix a bug if the bio is out of limits commit 5a266764fadaff8b5c1fe37a186ebf9b09cb953e upstream. If dm_integrity_check_limits fails, the code would exit with DM_MAPIO_KILL. However, the range would be already locked at this point, and it wouldn't be unlocked, resulting in a deadlock. Let's move the limit check up, so that when it exits, no resources are leaked. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Fixes: fb0987682c62 ("dm-integrity: introduce the Inline mode") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8f0af8493009a61b4313e0a8c6e03fbc36fd43f9 Author: Mikulas Patocka Date: Thu Jul 9 21:22:47 2026 +0200 dm-integrity: fix leaking uninitialized kernel memory commit 7bb03b2b01b814a9fc14afbfc2cbb2cca5b34750 upstream. If hash size is less than device's tuple size, dm-integrity is supposed to zero the remaining space. There was a bug in the code that zeroing didn't work. This commit fixes it. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Fixes: fb0987682c62 ("dm-integrity: introduce the Inline mode") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7d8ed7cb844df21e4d93af11250fb3a5cb861147 Author: Mikulas Patocka Date: Thu Jul 9 21:29:11 2026 +0200 dm_early_create: fix freeing used table on dm_resume failure commit 366665416f20527ff7cad548a32d1ddf23195740 upstream. If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Fixes: 6bbc923dfcf5 ("dm: add support to directly boot to a mapped device") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f00105be6a593920e9bc7949a069d4a116888851 Author: Ingo Blechschmidt Date: Wed Jun 17 16:33:42 2026 +0200 dm: avoid leaking the caller's thread keyring via the table device file commit 981ccd97f7153d310dfa92a534525bbaf46752c2 upstream. The refactoring in commit a28d893eb327 ("md: port block device access to file") accidentally causes the caller's thread keyring to be kept alive long beyond the caller's lifetime. As a result, "cryptsetup luksSuspend" silently fails to wipe the LUKS volume key from memory. In detail: "cryptsetup luksOpen" uses its supposedly ephemeral thread keyring to pass the volume key to the kernel. dm-crypt's crypt_set_keyring_key() copies the key material into its own crypt_config structure and then drops its own reference to the key in the keyring with key_put(). With this fix, restoring pre-v6.9 behavior, the copy in the thread keyring is then promptly garbage collected, such that exactly one copy of the volume key remains. This single copy is correctly wiped from memory on "cryptsetup luksSuspend". Without this fix, the thread keyring and the volume key in it remains. This second copy is only freed on "luksClose". "luksSuspend" neither knows about this copy nor has any way to remove it, so the key remains recoverable from RAM after a suspend that is documented to have wiped it. This fix should not introduce new security problems, as the code is anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling task, is the legitimate owner of this long-lived file. Fixes: a28d893eb327 ("md: port block device access to file") Closes: https://gitlab.com/cryptsetup/cryptsetup/-/work_items/993 Link: https://www.speicherleck.de/iblech/cryptsetup-luksSuspend-issue-reproduction/ Signed-off-by: Ingo Blechschmidt Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Tested-by: Ondrej Kozina Signed-off-by: Greg Kroah-Hartman commit 750b23d4935bb720806558da8bb583be80293fcf Author: Mikulas Patocka Date: Fri Jul 10 18:35:49 2026 +0200 dm-stats: fix merge accounting commit 1917eb2db750ecbdf710f79a8042eaa545a063c7 upstream. There were wrong parentheses when setting stats_aux->merged, so that merging was never properly accounted. This commit fixes it. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f3441b3bf5199f815240edbf24278d10a1a5c5e9 Author: Mikulas Patocka Date: Fri Jul 10 18:37:15 2026 +0200 dm-stats: fix dm_jiffies_to_msec64 commit 386df1a57b631c456d14f857cb0c0c2e11c16bef upstream. There were wrong calculations in dm_jiffies_to_msec64 that produced incorrect output when HZ was different from 1000. This commit fixes them. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0cbe13fe540330d31e5273bbf8cbd66bc7c9cb5a Author: Samuel Moelius Date: Mon Jun 29 15:47:40 2026 +0000 dm-pcache: reject option groups without values commit d9c631e3fbd44246a2be781d26cfacbb9b8ec127 upstream. The pcache target parses optional arguments as name/value pairs. A table that advertises one optional argument and supplies only a recognized option name, for example "cache_mode", reaches parse_cache_opts() with argc == 1. The parser consumes the name, decrements argc to zero, then calls dm_shift_arg() again for the value. dm_shift_arg() returns NULL when no arguments remain, and the following strcmp() dereferences that NULL pointer. Check that each recognized option has a value before consuming it. This keeps valid "cache_mode writeback" and "data_crc true/false" tables unchanged while making malformed tables fail during target construction with a precise missing-value error. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Reviewed-by: Zheng Gu Signed-off-by: Mikulas Patocka Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 79feb87ab2396d49b9b65e4bb815d33cc71cba47 Author: Benjamin Marzinski Date: Thu Jul 2 21:43:39 2026 -0400 dm-log: fix a bitset_size overflow on 32bit machines commit 9743132a41f4d9d0e54c5f2adcb821b04796bab1 upstream. Commit c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Fixes: c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit df50c24c6447c18886ed126d3d81cc7e155ea8b6 Author: Mikulas Patocka Date: Thu Jul 9 21:31:47 2026 +0200 dm-ioctl: fix a possible overflow in list_version_get_info commit 76c6f845dc0c614304a6e6ee619b552f97cf24b3 upstream. sizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the output buffer - info->vers->version[0], info->vers->version[1], info->vers->version[2] and info->vers->next. This can cause buffer overflow. Fix this buffer overflow by replacing "sizeof(tt->version)" with "sizeof(struct dm_target_versions)". Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4.6 Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 53477ce5ef9061a73650355572788db0bd8c26f6 Author: Mikulas Patocka Date: Fri Jul 10 18:32:49 2026 +0200 dm-bufio: fix wrong count calculation in dm_bufio_issue_discard commit 422f1d4f141eaa3a6e4199ceec86cc6b9bf26570 upstream. block_to_sector converts a block number to a sector number and adds c->start to the result. It is inappropriate to use this function for converting the number of blocks to a number to sectors because c->start would be incorrectly added to the result. Luckily, the only target that uses dm_bufio_issue_discard is dm-ebs, which sets c->start to 0, so this bug is latent. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Fixes: 6fbeb0048e6b ("dm bufio: implement discard") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bafe3e720cdac38cd7ea4eb7852a8f2dbe1bbfe6 Author: Samuel Moelius Date: Thu Jul 2 00:27:35 2026 +0000 dm era: fix out-of-bounds memory access for non-zero start sector commit a868196f03c2b19418ae3d2b69e195d668a271e5 upstream. dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: eec40579d848 ("dm: add era target") Signed-off-by: Greg Kroah-Hartman commit 9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0 Author: Ming-Hung Tsai Date: Tue Jun 30 20:17:44 2026 +0800 dm thin metadata: fix metadata snapshot consistency on commit failure commit 5bcd4d3058ebaf46ad2e163829d87dd4870c7a45 upstream. __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table "0 112 linear /dev/sdc 0 112 3984 error" 2. Create a 16 MiB thin-pool dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 "reserve_metadata_snap" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table "0 128 linear /dev/sdc 0 128 3968 error" 2. Create a 16 MiB thin-pool dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 "reserve_metadata_snap" dmsetup message tpool 0 "release_metadata_snap" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount. Fixes: 991d9fa02da0 ("dm: add thin provisioning target") Cc: stable@vger.kernel.org Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 0562bd39d361eaefeaf8bed2926a348bfbe4d83f Author: Genjian Zhang Date: Sat Jul 11 18:05:26 2026 +0800 dm thin metadata: fix superblock refcount leak on snapshot shadow failure commit 4b22d0801fadfcae2e106e6ba32e49439c7c7ebf upstream. __reserve_metadata_snap() increments THIN_SUPERBLOCK_LOCATION in the metadata space map before shadowing it. When dm_tm_shadow_block() fails, a reference is leaked in the metadata space map. Fix by adding the missing dm_sm_dec_block(). Signed-off-by: Genjian Zhang Signed-off-by: Mikulas Patocka Fixes: cc8394d86f04 ("dm thin: provide userspace access to pool metadata") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 17f113e7b622dc850992ade540181717de6a8561 Author: Haoxiang Li Date: Tue Jun 23 19:57:14 2026 +0800 net: sparx5: unregister blocking notifier on init failure commit 483be61b4a9a6df3b7cb277e8f189e082dee4cb8 upstream. sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there. Fixes: d6fce5141929 ("net: sparx5: add switching support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260623115714.2192074-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d4cc255f35d5f47dfd878f2270cb605443a087da Author: Yitang Yang Date: Tue Jun 16 23:51:29 2026 +0800 block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd commit 4f919141be38ea2b1314e3a531b7b998eb64e8bc upstream. blkdev_uring_cmd() checks IORING_URING_CMD_REISSUE to determine whether this is the first issue. However, this flag lives in cmd->flags instead of issue_flags. Coincidentally, IO_URING_F_NONBLOCK shares bit 31 with IORING_URING_CMD_REISSUE. As a result, the SQE read was never performed, bic->len remained zero, and every BLOCK_URING_CMD_DISCARD failed with -EINVAL. Fix it by checking cmd->flags as intended. Cc: stable@vger.kernel.org Fixes: 212ec34e4e72 ("block: only read from sqe on initial invocation of blkdev_uring_cmd") Signed-off-by: Yitang Yang Link: https://patch.msgid.link/20260616155129.406057-1-yi1tang.yang@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c0f10f43ffa5d5feaddc62df1de553bb50d01e27 Author: Mike Waychison Date: Wed Jul 15 15:29:50 2026 -0400 block: fix race in blk_time_get_ns() returning 0 commit 691b052139c94ee6640ac39e0b764dd3867897c0 upstream. blk_time_get_ns() populates the per-plug cached timestamp and then returns it by re-reading the field: if (!plug->cur_ktime) { plug->cur_ktime = ktime_get_ns(); current->flags |= PF_BLOCK_TS; } return plug->cur_ktime; This is problematic when the compiler emits the final "return plug->cur_ktime" as a reload from memory, after PF_BLOCK_TS has already been set. Since the cached timestamp is now invalidated from finish_task_switch() (fad156c2af22 "block: invalidate cached plug timestamp after task switch"), a task preempted between setting PF_BLOCK_TS and that reload has plug->cur_ktime zeroed by blk_plug_invalidate_ts() when it is scheduled back in. The reload then returns 0. A 0 handed back here is stored as a start timestamp -- e.g. blk_account_io_start() writes it to rq->start_time_ns -- and later subtracted from "now". blk_account_io_done() then adds (now - 0), i.e. roughly the system uptime, to the per-group nsecs[] counters. On an otherwise idle, healthy device this appears as sudden ~uptime-sized jumps in the diskstats time fields (write_ticks/discard_ticks/time_in_queue). The solution is to be explicit in our reads and writes to this field that is preemption volatile. We also add a barrier() to ensure that any setting of PF_BLOCK_TS is ordered to happen after the cur_ktime update. This issue was discovered using AI-assisted kprobes looking for paths that were leaking zeroed timestamps in a live system, based on the observation that we were sometimes seeing uptime-sized jumps in kernel exported counters. This was flagged by NodeDiskIOSaturation prometheus alerts that started firing on all hosts post 7.1.3 kernel upgrade, due to node-exporter now exporting a nonsensical node_disk_io_time_weighted_seconds_total. Fixes: fad156c2af22 ("block: invalidate cached plug timestamp after task switch") Cc: stable@vger.kernel.org Signed-off-by: Mike Waychison Assisted-by: Claude:claude-opus-4.8 Link: https://patch.msgid.link/20260715192950.2488921-1-mike@waychison.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 02f8ad12545cb05656a5a20bc52f41f0367ab3e6 Author: Connor Williamson Date: Mon Jun 15 13:07:15 2026 +0000 block: remove redundant GD_NEED_PART_SCAN in add_disk_final() commit 181bb9c9eae4f69fe510a62a42c2932d0314a800 upstream. add_disk_final() sets GD_NEED_PART_SCAN before calling bdev_add(), then calls disk_scan_partitions() which sets the flag itself. The early set is redundant and introduces a race. Between bdev_add() and disk_scan_partitions(), concurrent openers (multipathd, blkid, LVM) see the flag in blkdev_get_whole() and trigger bdev_disk_changed(). When disk_scan_partitions() then runs, it calls bdev_disk_changed() again, dropping the partitions the concurrent opener already created before re-adding them, which can result in transient partition disappearances. The race is observable by inserting an msleep() between bdev_add() and disk_scan_partitions() while running concurrent open() calls during device bind. Without artificial delay, it manifests under scheduling pressure during boot on systems with aggressive device scanners (multipathd, systemd-udevd). Therefore, do not set GD_NEED_PART_SCAN in add_disk_final(). Other GD_NEED_PART_SCAN consumers (blkdev_get_whole(), sd_need_revalidate()) should not be affected as the flag is set internally by disk_scan_partitions(). The retry-on-next-open intention from commit e5cfefa97bcc ("block: fix scan partition for exclusively open device again") should also not be affected as the early return paths in disk_scan_partitions() should be unreachable at device registration time (bd_holder is NULL and open_partitions is zero). Fixes: e5cfefa97bcc ("block: fix scan partition for exclusively open device again") Cc: stable@vger.kernel.org Signed-off-by: Connor Williamson Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260615130715.53693-1-connordw@amazon.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fe1d9121b4b75154f28e1940abf28323c85afc41 Author: Sun Jian Date: Tue Jul 14 02:38:46 2026 -0700 selftests/bpf: Cover negative buffer pointer offsets commit 6f59deb32efa4673fc3b1fef9f3a0da48e9d8494 upstream. Add verifier coverage for constant negative offsets on PTR_TO_TP_BUFFER and PTR_TO_BUF pointers. Both programs adjust the buffer pointer by -8 and access it at offset zero, so the negative effective start must be rejected at load time. Switch the raw tracepoint writable attach checks from nbd_send_request to bpf_testmod_test_writable_bare_tp, avoiding a dependency on the NBD tracepoint. Keep the existing past-end case and add a case with a negative var_off compensated by a positive instruction offset. The effective start remains non-negative, so the program loads, but its access end exceeds the writable context size and bpf_raw_tracepoint_open() must return -EINVAL. Cc: stable@vger.kernel.org # 5.2.0 Signed-off-by: Sun Jian Acked-by: Shung-Hsi Yu Link: https://patch.msgid.link/20260714093846.18159-3-sun.jian.kdev@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Greg Kroah-Hartman commit 28ce7bcf8a29aa395b60764df4c97be745de89d0 Author: Jiri Olsa Date: Tue Jun 16 10:30:56 2026 +0200 bpf: Add missing access_ok call to copy_user_syms commit d5dc200c3a3f217de072af269dd90adddf90e48d upstream. As reported by sashiko we use __get_user without prior access_ok call on the user space pointer. Adding the missing call for the whole pointer array. Plus removing the err check in the error path, because it's not needed and also we can return -ENOMEM directly from the first kvmalloc_array fail path. Cc: stable@vger.kernel.org [1] https://lore.kernel.org/bpf/20260611115503.AC16D1F00893@smtp.kernel.org/ Fixes: 0236fec57a15 ("bpf: Resolve symbols with ftrace_lookup_symbols for kprobe multi link") Reported-by: Sashiko Closes: https://lore.kernel.org/bpf/20260611115503.AC16D1F00893@smtp.kernel.org/ Signed-off-by: Jiri Olsa Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260616083056.405652-1-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 43f0005f81b8ce3be962d653cde8db9022f1e9b0 Author: Jann Horn Date: Fri Jun 26 17:52:52 2026 +0200 bpf,fork: wipe ->bpf_storage before bailouts that access it commit 9b51a6155d14389876916726430da30eabb1d4ed upstream. Currently, copy_process() can bail out to free_task() before p->bpf_storage has been initialized, with this call graph (shown here for the !CONFIG_MEMCG case): copy_process dup_task_struct arch_dup_task_struct [copies the entire task_struct, including ->bpf_storage member] [RLIMIT_NPROC check fails] delayed_free_task free_task bpf_task_storage_free rcu_dereference(task->bpf_storage) bpf_local_storage_destroy In this case, the nascent task's ->bpf_storage member that bpf_local_storage_destroy() operates on is a plain copy of the parent's ->bpf_storage pointer, not a real initialized pointer. This leads to badness (kernel hangs, UAF). This is reachable as long as the process calling fork() has been inserted into a task storage map. Cc: stable@kernel.org Fixes: a10787e6d58c ("bpf: Enable task local storage for tracing programs") Signed-off-by: Jann Horn Signed-off-by: Andrii Nakryiko Signed-off-by: Greg Kroah-Hartman commit 5a55f9aecc08990940e70f0c7048a80850c5a16a Author: Tristan Madani Date: Mon Jun 22 23:01:22 2026 +0000 bpf: Reset register bounds before narrowing retval range in check_mem_access() commit 5e0b273e0a62cc04ec338c7b502797c66c2ed42a upstream. When the BPF verifier processes a context load of an LSM hook return value, it calls __mark_reg_s32_range() to narrow the register to the hook's valid range. However, __mark_reg_s32_range() intersects the new range with the register's existing bounds using max_t()/min_t() rather than replacing them. If the destination register carries stale bounds from a prior instruction (e.g. BPF_MOV64_IMM), the intersection can produce a range narrower than reality. The verifier then believes it knows the register's exact value, while at runtime the actual hook return value is loaded, creating a verifier/runtime mismatch that can be used to bypass BPF memory safety checks. The else branch already calls mark_reg_unknown() to reset register state before any narrowing. Apply the same reset in the is_retval path so stale bounds are cleared before __mark_reg_s32_range() intersects. Fixes: 5d99e198be27 ("bpf, lsm: Add check for BPF LSM return value") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260622230123.3695446-2-tristmd@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 0639ea767fe04c288a8d6cb826100fe3d95d4936 Author: Woraphat Khiaodaeng Date: Fri Jul 17 22:45:37 2026 +0700 io_uring/bpf-ops: reject re-registration of an already-bound ops commit 3afc64c61ce906a04f073ca350b46de10e8302f9 upstream. io_install_bpf() only rejects a second registration on the ctx side (ctx->bpf_ops) and sets the per-map back-pointer ops->priv unconditionally. The struct_ops link path never advances a map past BPF_STRUCT_OPS_STATE_READY, so the same io_uring_bpf_ops map can be registered more than once, and bpf_io_reg() re-resolves the target ring via fget(ops->ring_fd) on every call. A caller can therefore point the same ring_fd at a different io_ring_ctx between two BPF_LINK_CREATE calls. The second registration passes the ctx->bpf_ops check (the new ctx has none) and overwrites ops->priv, orphaning the first ctx. Teardown (io_eject_bpf()/bpf_io_unreg()) only reaches a ctx through ops->priv, so the orphaned ctx is never torn down: its ctx->loop_step keeps pointing into the struct_ops trampoline, which is freed once the map is gone. A later io_uring_enter() on the orphaned ring then calls the dangling ctx->loop_step from io_run_loop() -- a use-after-free of freed executable memory, reachable by a task with CAP_BPF + CAP_PERFMON. Reject registration when ops->priv is already set, as hid_bpf_reg() does for its struct_ops. Cc: stable@vger.kernel.org Fixes: 98f37634b12b ("io_uring/bpf-ops: implement bpf ops registration") Signed-off-by: Woraphat Khiaodaeng Reviewed-by: Gabriel Krisman Bertazi Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/20260717154537.129736-1-worapat.kd2@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 04d23061bbf18d5d81022eb21e9d32e99d24468d Author: Oliver Hartkopp Date: Tue Jul 14 18:55:30 2026 +0200 can: bcm: add missing device refcount for CAN filter removal commit d59948293ea34b6337ce2b5febab8510de70048c upstream. sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 ("can: raw: add missing refcount for memory leak fix") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260707094716.63578-1-socketcan@hartkopp.net Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-8-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 59bfddea64159594feb62ef11b7d7a33c8ee3783 Author: Oliver Hartkopp Date: Tue Jul 14 18:55:29 2026 +0200 can: bcm: validate frame length in bcm_rx_setup() for RTR replies commit 62ec41f364648be79d54d94d0d240ee326948afd upstream. bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-7-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b6317022b685a430a3ae420456716e3c0c02ef4b Author: Oliver Hartkopp Date: Tue Jul 14 18:55:33 2026 +0200 can: bcm: track a single source interface for ANYDEV timeout/throttle ops commit 2f5976f54a04e9f18b25283036ac3136be453b17 upstream. An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net(). Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260709105031.1A39C1F000E9@smtp.kernel.org/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-11-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b31d0933509c5a35c0be5736a2ce8df0d1bf112c Author: Oliver Hartkopp Date: Tue Jul 14 18:55:31 2026 +0200 can: bcm: fix stale rx/tx ops after device removal commit 3b762c0d950383ab7a002686c9136b9aa55d2d70 upstream. RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260708094536.DDF821F00A3A@smtp.kernel.org/ Closes: https://lore.kernel.org/linux-can/20260708154039.347ED1F000E9@smtp.kernel.org/ Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-9-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit c312b750bb5ac3348cfc85dab25e90937bd4d251 Author: Oliver Hartkopp Date: Tue Jul 14 18:55:32 2026 +0200 can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() commit 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 upstream. For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260707145135.5BC831F00A3A@smtp.kernel.org/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-10-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit df47f07cdc801a6afe05a486b5a343c3e532a93c Author: Oliver Hartkopp Date: Tue Jul 14 18:55:26 2026 +0200 can: bcm: fix CAN frame rx/tx statistics commit e6c24ba95fc3f1b5e1dcd28b1c6e59ef61a9daa5 upstream. KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-4-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 337f966c00662d81ad82cf5a4bbb150b2e32c0d4 Author: Oliver Hartkopp Date: Tue Jul 14 18:55:28 2026 +0200 can: bcm: extend bcm_tx_lock usage for data and timer updates commit 12ce799f7ab1e05bd8fbf79e46f403bfe5597ebc upstream. Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-6-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 30f7bb922cb7e7f072a56c7cb7a5efccd2ceca1d Author: Oliver Hartkopp Date: Tue Jul 14 18:55:27 2026 +0200 can: bcm: add missing rcu list annotations and operations commit 7b2c3eabc4dafc062a25e10711154f2107526a78 upstream. sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op(). Reported-by: sashiko-reviews@lists.linux.dev Closes: https://lore.kernel.org/linux-can/20260610094654.A1FFE1F00893@smtp.kernel.org/ Fixes: dac5e6249159 ("can: bcm: add missing rcu read protection for procfs content") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-5-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit fc9f5ee1b073bd233d9c604e338af4ebb42cbc33 Author: Oliver Hartkopp Date: Tue Jul 14 18:55:25 2026 +0200 can: bcm: add locking when updating filter and timer values commit 749179c2e25b95d22499ed29096b3e02d6dfd2b4 upstream. KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Reported-by: syzbot+75e5e4ae00c3b4bb544e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-can/6975d5cf.a00a0220.33ccc7.0022.GAE@google.com/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-3-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b9c6ac6fb4e01b34575816066e5d3890a57b3c86 Author: Oliver Hartkopp Date: Tue Jul 14 18:55:24 2026 +0200 can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure commit d9b091d9d22fee81ec53fb55d2032951993ceadb upstream. bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches "any" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: Ginger Closes: https://lore.kernel.org/linux-can/CAGp+u1aBK8QVjsvAxM2Ldzep4rEbsP9x_pV3At4g=h1kVEtyhA@mail.gmail.com/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-2-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ce2d4b121fb7545e1ed588e860c8e5fd5ad45224 Author: Lee Jones Date: Tue Jul 14 18:55:23 2026 +0200 can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF commit 68973f9db76144825e4f35dfdc80fb8279eb2d57 upstream. Commit f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly synchronize_rcu()") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a "scheduling while atomic" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk. Fixes: f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly synchronize_rcu()") Tested-by: Feng Xue Tested-by: Oliver Hartkopp Signed-off-by: Lee Jones Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-1-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 4f1fdf1a1c317bcac0c6b6c8e12642c9983de1ca Author: Oliver Hartkopp Date: Sun Jul 12 19:59:43 2026 +0200 can: isotp: serialize TX state transitions under so->rx_lock commit cf070fe33bfbd1a4c21236078fadb35dd223a157 upstream. The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260710142146.BDAE61F000E9@smtp.kernel.org/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260712-isotp-fixes-v10-3-793a1b1ce17f@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e442b62ba5a7756c17e05a77b32cdd085a2b6138 Author: Oliver Hartkopp Date: Sun Jul 12 19:59:42 2026 +0200 can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER commit 20bab8b88baac140ca3701116e1d486c7f51e311 upstream. isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260707101420.47F261F000E9@smtp.kernel.org/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260712-isotp-fixes-v10-2-793a1b1ce17f@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b8278ff605187ef3fa0f2705e93251cce4c4f8ee Author: Oliver Hartkopp Date: Sun Jul 12 19:59:41 2026 +0200 can: isotp: use unconditional synchronize_rcu() in isotp_release() commit 9b1a02e0d980ac6b0e36a90378f847062f81d7e4 upstream. isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path. Fixes: 14a4696bc311 ("can: isotp: isotp_release(): omit unintended hrtimer restart on socket release") Closes: https://lore.kernel.org/linux-can/20260707085210.6B6C01F000E9@smtp.kernel.org/ Reported-by: Nico Yip Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260712-isotp-fixes-v10-1-793a1b1ce17f@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5832c55b3c824ba2fe9c36ac3c411baddcce053e Author: Fan Wu Date: Thu Jul 9 16:41:59 2026 +0000 can: esd_usb: kill anchored URBs before freeing netdevs commit c43122fef328a70045fe7621c06de6b2b8e19264 upstream. esd_usb_disconnect() frees each CAN netdev with free_candev() inside its per-netdev loop and only calls unlink_all_urbs(dev) afterwards. The per-netdev private data (struct esd_usb_net_priv) is embedded in the net_device allocation returned by alloc_candev(), so once free_candev() has run, dev->nets[i] points to freed memory. unlink_all_urbs() then dereferences the freed dev->nets[i] to kill the per-netdev TX anchor (usb_kill_anchored_urbs(&priv->tx_submitted)), clear active_tx_jobs, and reset priv->tx_contexts[]. Reorder the teardown so the anchored URBs are killed before the netdevs are freed, matching other CAN/USB drivers in the same directory such as ems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then free: unregister the netdevs first (which stops their TX queues), call unlink_all_urbs(dev) once, then free the netdevs. This issue was found by an in-house static analysis tool. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260709164159.497640-1-fanwu01@zju.edu.cn Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 046380f3e1112525715816a3f25bfb8bfa0a5e92 Author: Souvik Banerjee Date: Fri May 1 23:27:35 2026 +0000 ovl: use linked upper dentry in copy-up tmpfile commit e348eecd4d8fa8d18a5157ff59f7be1dc59c5928 upstream. ovl_copy_up_tmpfile() stores the disconnected O_TMPFILE dentry as the overlay's upper dentry reference via ovl_inode_update(). vfs_tmpfile() allocated this dentry via d_alloc(parentpath->dentry, &slash_name), so d_name is "/" and d_parent is c->workdir. Local upper filesystems (ext4, btrfs, xfs, ...) immediately rename it to "#" via d_mark_tmpfile() inside their ->tmpfile() op; FUSE and virtiofs do not, so both fields stay that way. Neither identifies the destination directory and filename where ovl_do_link() actually linked the file. When the upper filesystem implements ->d_revalidate() (e.g. FUSE or virtiofs), ovl_revalidate_real() calls it with the dentry's parent inode and a snapshot of d_name. The server tries to look up "/" inside c->workdir, fails, and overlayfs reports -ESTALE. This causes persistent ESTALE errors for any file that was copied up via the tmpfile path, breaking dpkg, apt, and other tools that do rename-over-existing on overlayfs with a FUSE/virtiofs upper. Before commit 6b52243f633e ("ovl: fold copy-up helpers into callers"), the tmpfile copy-up path used a dedicated helper ovl_link_tmpfile() that captured the linked destination dentry returned by ovl_do_link(): err = ovl_do_link(temp, udir, upper); ... if (!err) *newdentry = dget(upper); and published it via ovl_inode_update(d_inode(c->dentry), newdentry). The fold inlined ovl_do_link() into ovl_copy_up_tmpfile() but dropped the dget(upper) capture, and rewrote the publish line as ovl_inode_update(d_inode(c->dentry), dget(temp)) — where temp is the disconnected O_TMPFILE dentry. Fix by keeping a reference to the linked destination dentry after ovl_do_link() succeeds, and publishing that dentry at the existing ovl_inode_update() call site. The non-tmpfile/workdir path continues to publish the renamed temporary dentry. Reproducer: - Mount overlayfs with virtiofs (or a FUSE fs whose server advertises FUSE_TMPFILE) as upper - Run: dpkg -i - Observe: "error installing new file '...': Stale file handle" Fixes: 6b52243f633e ("ovl: fold copy-up helpers into callers") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Souvik Banerjee Link: https://patch.msgid.link/20260501232735.2610824-1-souvik@amlalabs.com Reviewed-by: Amir Goldstein Reviewed-by: Miklos Szeredi Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit fd750b694f1f9e1ecb8ca19314e4e21edbb15f42 Author: Maoyi Xie Date: Tue Jun 16 01:17:36 2026 +0800 netdev-genl: report NAPI thread PID in the caller's pid namespace commit 1f24c0d01db214c9e661915e9972404c96ca73c0 upstream. netdev_nl_napi_fill_one() reports the NAPI kthread PID in NETDEV_A_NAPI_PID using task_pid_nr(), which returns the PID in the initial pid namespace. NETDEV_CMD_NAPI_GET does not have GENL_ADMIN_PERM and the netdev genl family is netnsok, so a caller in a child pid namespace can issue it. That caller then sees the kthread's global PID, even though the kthread is not visible in its pid namespace, where the value should be 0. Translate the PID through the caller's pid namespace, the same way commit 3799c2570982 ("io_uring/fdinfo: translate SqThread PID through caller's pid_ns") did for the io_uring SQPOLL thread. The doit and dumpit paths both run synchronously in the caller's context, so task_active_pid_ns(current) is the caller's pid namespace. Fixes: db4704f4e4df ("netdev-genl: Add PID for the NAPI thread") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Joe Damato Reviewed-by: Samiullah Khawaja Link: https://patch.msgid.link/20260615171736.1709318-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fcef60ed5f714a24104eb021d6397a67955ebeff Author: Wentao Liang Date: Tue Jun 9 09:55:05 2026 +0000 nvmet: fix refcount leak in nvmet_sq_create() commit 34b9a83c50660148bde01cde16451dbe78369749 upstream. In nvmet_sq_create(), a reference on the ctrl is taken via kref_get_unless_zero() before calling nvmet_check_sqid(). If nvmet_check_sqid() fails, the function returns the error directly without releasing the reference, leading to a leak. Fix this by jumping to the "ctrl_put" label, which already performs the necessary nvmet_ctrl_put(ctrl). This ensures the reference is properly released on this error path. Cc: stable@vger.kernel.org Fixes: 1eb380caf527 ("nvmet: Introduce nvmet_sq_create() and nvmet_cq_create()") Signed-off-by: Wentao Liang Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 98bcdfa619150b2f41fa15bac140dbaf2584ad05 Author: Bryam Vargas Date: Thu Jun 4 19:36:54 2026 +0000 nvmet-rdma: handle inline data with a nonzero offset commit 48c0162f647bb47e6084ffbc71b8f213f5e2f4f8 upstream. nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: sg->offset = off; sg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()). Fixes: 0d5ee2b2ab4f ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data") Cc: stable@vger.kernel.org Suggested-by: Keith Busch Reported-by: Bryam Vargas Signed-off-by: Bryam Vargas Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit bc111698b46e43eddd8664cceaa621cd559e99a0 Author: Michael Bommarito Date: Tue Jun 9 14:24:31 2026 -0400 nvmet-auth: reject short AUTH_RECEIVE buffers commit 779575bc35c687697ba69e904f2cd22e60112534 upstream. nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Hannes Reinecke Signed-off-by: Michael Bommarito Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit b7d9aaedf024bb6c0bb6a205848861d888eb1afa Author: Nick Chan Date: Sun Jun 7 14:10:58 2026 +0800 nvme-apple: Prevent shared tags across queues on Apple A11 commit 6fe0687245e8406bf26143bd45eb16441bbe5280 upstream. On Apple A11, tags of pending commands must be unique across the admin and IO queues, else the firmware crashes with "duplicate tag error for tag N", with N being the tag. Apply the existing workaround for M1 of reserving two tags for the admin queue to A11. Cc: stable@vger.kernel.org Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support") Reviewed-by: Sven Peter Signed-off-by: Nick Chan Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit a192b6c149c6ea10cc88869accb78165eb454456 Author: Benjamin Coddington Date: Tue Jul 7 11:07:16 2026 -0400 NFS: Charge unstable writes by request size, not folio size commit 27934d02cbeb8a957dd11c985a579e58d30c5270 upstream. nfs_folio_mark_unstable() and nfs_folio_clear_commit() charge and uncharge NR_WRITEBACK/WB_WRITEBACK by folio_nr_pages(folio) once per *request* added to or removed from a commit list. This is correct only when a folio has a single associated request. When pg_test splits a folio into N sub-folio requests (e.g. pNFS flexfiles striping with a stripe unit smaller than the folio size, or plain wsize-limited splitting), each of the N requests independently charges the whole folio's page count, inflating the accounting by a factor of N per folio. With large folios and small stripe units this reaches multiple orders of magnitude: a 2 MiB folio split into 512 4 KiB requests can charge up to 512x its real size, pushing global dirty+writeback accounting past the system's dirty threshold and forcing every buffered writer on the host into the hard-throttle path, including unrelated in-kernel NFS server threads sharing the box. Charge each request only for the pages it actually covers. Fixes: 0c493b5cf16e ("NFS: Convert buffered writes to use folios") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Coddington Assisted-By: Claude Sonnet 5 Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0 Author: Weiming Shi Date: Fri Jul 3 20:35:46 2026 -0700 sctp: validate STALE_COOKIE cause length before reading staleness commit 1cd23ca80784223fa2204e16203f754da4e821f8 upstream. When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: err = (struct sctp_errhdr *)(chunk->skb->data); stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi Acked-by: Xin Long Link: https://patch.msgid.link/20260704033545.2438373-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 077a7bc1c32d3da9670c5e282ea3e5ac8a94be59 Author: Kunihiko Hayashi Date: Tue Jun 16 10:12:23 2026 +0900 spi: uniphier: Fix completion initialization order before devm_request_irq() commit f3ad1c87d8201e54b66bd6072442f0b5d5a308ee upstream. The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ. Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC") Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Signed-off-by: Kunihiko Hayashi Reviewed-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260616011223.201357-1-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 40dee2d3e9994aed9efe7bed40eb0e4d38d5a25c Author: Javier Fernandez Pastrana Date: Wed Jun 24 17:19:58 2026 +0200 spi: imx: reconfigure for PIO when DMA cannot be started commit 245404c26563aafb36aafb01298f148db1851be3 upstream. When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA: spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the SDMA watermarks. If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single() returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and falls back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of the SPI core's mapping, so xfer->{tx,rx}_sg_mapped are not set and the core's DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst length and dynamic_burst cleared, and the transferred data is corrupted. This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin): every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns shifted TPM2_GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is never created. Set controller->fallback before re-running spi_imx_setupxfer() so the ECSPI is reconfigured exactly like a normal PIO transfer. With controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma() return false, so it clears spi_imx->usedma and reprograms the controller (clears CTRL.SMC, restores dynamic_burst and the PIO burst length). No explicit spi_imx->usedma = false is needed: setupxfer() already updates it from the can_dma() result. Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode") Cc: stable@vger.kernel.org Signed-off-by: Javier Fernandez Pastrana Acked-by: Carlos Song Reviewed-by: Frank Li Link: https://patch.msgid.link/20260624151958.18626-1-javier.pastrana@linutronix.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 91376c61a5fd77c989230bcd33fb51d21b40d55c Author: Wang Yan Date: Mon Jun 22 18:33:48 2026 +0800 time: Fix off-by-one in compat settimeofday() usec validation commit 269f2b43fae692d1f3988c9f888a6301aa537b82 upstream. The compat version of settimeofday() uses '>' instead of '>=' when validating tv_usec against USEC_PER_SEC, allowing the value 1000000 to pass the check. After the subsequent conversion to nanoseconds (tv_nsec *= NSEC_PER_USEC), this results in tv_nsec == NSEC_PER_SEC, which violates the timespec invariant that tv_nsec must be strictly less than NSEC_PER_SEC. The native settimeofday() was already fixed in commit ce4abda5e126 ("time: Fix off-by-one in settimeofday() usec validation"), but the compat counterpart was missed. Fix it by using '>=' to reject tv_usec values outside the valid range [0, USEC_PER_SEC - 1]. Fixes: 5e0fb1b57bea ("y2038: time: avoid timespec usage in settimeofday()") Signed-off-by: Wang Yan Signed-off-by: Thomas Gleixner Acked-by: Arnd Bergmann Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260622103348.120255-1-wangyan01@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 947b773caaa548672184df025271b29bdc80b0f1 Author: Jaewon Yang Date: Mon Jul 13 02:11:47 2026 +0900 tpm: Make the TPM character devices non-seekable commit f20d61c22bcaf172d6790b6500e3838e532e71c8 upstream. The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced. Fixes: 9488585b21be ("tpm: add support for partial reads") Link: https://lore.kernel.org/all/20260710090217.191289-1-yong010301@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Jaewon Yang Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 98fa6e42fd51f9d1a9fdc4f46dcb705d758b3dc0 Author: Thorsten Blum Date: Mon Jun 15 15:02:05 2026 +0300 tpm: fix event_size output in tpm1_binary_bios_measurements_show commit 1a58f6115bfb34eabcc7de8a3a9745b219179781 upstream. Commit 186d124f07da ("tpm_eventlog.c: fix binary_bios_measurements") split the output to write the endian-converted event header first and then the variable-length event data. However, the split was at sizeof(struct tcpa_event) - 1, even though event_data was a zero-length array, and later a flexible array member, both of which already excluded the event data. Therefore, the current code writes the first three bytes of event_size from the endian-converted header and then the last byte from the raw header, which can emit a corrupted event_size on PPC64, where do_endian_conversion() maps to be32_to_cpu(). Split one byte later to write the full endian-converted header first, followed by the variable-length event->event_data. Fixes: 186d124f07da ("tpm_eventlog.c: fix binary_bios_measurements") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Thorsten Blum Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 3ba2b2ef7d6a63b190f15cfc2b4ba0fba59928ea Author: Maoyi Xie Date: Fri Jun 12 16:59:41 2026 +0800 xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink commit 095515d89b19b6cc19dfcdc846f97403ed1ebce3 upstream. xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-8-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b4e9dcf4143ec27e52a017687ed75715358cc209 Author: Sanman Pradhan Date: Sun Jun 7 16:47:34 2026 +0000 xfrm: use compat translator only for u64 alignment mismatch commit 355fbcbdc2539cca7890b0d0914d4ce0f985ad74 upstream. The XFRM compat layer (CONFIG_XFRM_USER_COMPAT) translates 32-bit xfrm netlink and setsockopt messages into the native 64-bit layout. It is only needed on architectures where the 32-bit and 64-bit ABIs disagree on u64 alignment, which the kernel encodes as COMPAT_FOR_U64_ALIGNMENT. That symbol is defined only by arch/x86. XFRM_USER_COMPAT depends on it, so the translator can never be built on any other architecture, including arm64, which still provides a 32-bit compat ABI (CONFIG_COMPAT) for AArch32 EL0 userspace. On arm64 the AArch32 EABI already aligns u64 to 8 bytes, identical to the AArch64 ABI, so no translation is required and the native code path is correct for 32-bit tasks. However, xfrm_user_rcv_msg() and xfrm_user_policy() gate on in_compat_syscall() alone and then call xfrm_get_translator(), which returns NULL when no translator is registered. On arm64 that is always the case, so every xfrm netlink message and the XFRM_POLICY setsockopt issued by a 32-bit task returns -EOPNOTSUPP. A 32-bit userspace process on arm64 (and on any other arch with CONFIG_COMPAT but without COMPAT_FOR_U64_ALIGNMENT) therefore cannot configure XFRM state or policy through the XFRM_USER netlink API, and cannot use the XFRM_POLICY setsockopt path, because both fail before reaching the native parser. The translator series replaced the blanket compat rejection with a translator lookup. That made the path usable on x86 when the translator is available, but left architectures that cannot build the translator permanently rejected even when their compat layout already matches the native layout. Let those architectures use the native parser instead. Gate the translator requirement on COMPAT_FOR_U64_ALIGNMENT instead of on in_compat_syscall() alone. Gating on the ABI property rather than on CONFIG_XFRM_USER_COMPAT is deliberate: on x86 with IA32_EMULATION=y but XFRM_USER_COMPAT=n, a 32-bit task must still be rejected rather than routed through the native parser, which would misread genuinely 4-byte-aligned x86-32 messages. COMPAT_FOR_U64_ALIGNMENT is the ABI property that makes the XFRM translator mandatory. Only the receive/input direction needs the guard. The send, dump and notification paths already call the translator as "if (xtr) { ... }" with no error on NULL, so on arches without a translator they no-op and the kernel emits native 64-bit-layout messages, which is what an AArch32 task expects. Tested on Juniper SRX hardware: with the fix, 32-bit IPsec userspace netlink and XFRM_POLICY setsockopt operations that previously failed with -EOPNOTSUPP now succeed; x86 behaviour is unchanged by inspection. Fixes: 5106f4a8acff ("xfrm/compat: Add 32=>64-bit messages translator") Fixes: 96392ee5a13b ("xfrm/compat: Translate 32-bit user_policy from sockptr") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit a8a7e6a9ff8a4c1f067694ddbd44be67fdf36693 Author: Qianyu Luo Date: Thu Jun 25 13:55:08 2026 +0800 xfrm: nat_keepalive: avoid double free on send error commit 226f4a490d1a938fc838d8f8c46a4eca864c0d78 upstream. nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path. Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Signed-off-by: Qianyu Luo Signed-off-by: Ren Wei Reviewed-by: Eyal Birger Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 6883269a323609f68f6faa903f8f8ff3d191cec8 Author: Wentao Liang Date: Mon Jun 22 19:25:41 2026 +0800 xen/gntdev: fix error handling in ioctl commit 45ca1afe2fd14c04e37227e79d3f8455831d8408 upstream. When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Cc: stable@vger.kernel.org Fix these issues by properly handling all error cases. Fixes: 1401c00e59ea ("xen/gntdev: convert priv->lock to a mutex") Fixes: 68b025c813c2 ("xen-gntdev: Add reference counting to maps") Signed-off-by: Wentao Liang Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260622112541.38194-1-vulab@iscas.ac.cn> Signed-off-by: Greg Kroah-Hartman commit 2510434307a224078302019e52ab3c863fbe87fb Author: Steven Rostedt Date: Tue Jun 30 18:54:12 2026 -0400 ufs: core: tracing: Do not dereference pointers in TP_printk() commit 535fcf4b8a261fbb8cc4f91e4597343c135a90f2 upstream. The trace events in drivers/ufs/core/ufs_trace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TP_printk() the printing of the dev_name from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer. This is not allowed as the TP_printk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read. Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TP_printk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel. This was detected when testing the trace event code that looks for TP_printk() parameters doing illegal derferences[1] [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260630185412.283c26c5@gandalf.local.home Fixes: 583e518e71003 ("scsi: ufs: core: Add hba parameter to trace events") Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f48d3ae9d320862d88c046daa9ddeb1e73d9d72b Author: Dmitry Safonov <0x7f454c46@gmail.com> Date: Thu Jun 25 19:21:41 2026 +0100 tcp: Decrement tcp_md5_needed static branch commit 6f6e860e370c9e4e919b92118a25e9e1f82e9180 upstream. In case of early freeing an unwanted TCP-MD5 key on TCP-AO connect(), md5sig_info is freed right away (and set to NULL). Later, at the moment of socket destruction, the static branch counter is not getting decremented. Add a missing decrement for TCP-MD5 static branch. Reported-by: Qihang Fixes: 0aadc73995d0 ("net/tcp: Prevent TCP-MD5 with TCP-AO being set") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260625-tcp-md5-connect-v3-3-1fd313d6c1e0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit da48b9bf1eb95a9cfd09d615ca58cfc2b03de369 Author: Michael Bommarito Date: Thu Jun 25 19:21:40 2026 +0100 tcp: defer md5sig_info kfree past RCU grace period in tcp_connect commit b74cd55038905d5e74c1de109ab78a30b2ea0e1f upstream. The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: if (needs_md5) { tcp_ao_destroy_sock(sk, false); } else if (needs_ao) { tcp_clear_md5_list(sk); kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); } Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. Fixes: 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") Cc: stable@vger.kernel.org # v6.18+ Suggested-by: Eric Dumazet Signed-off-by: Michael Bommarito Reviewed-by: Dmitry Safonov Reviewed-by: Eric Dumazet [also credits to Qihang, who found that this races with tcp-diag] Reported-by: Qihang Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260625-tcp-md5-connect-v3-2-1fd313d6c1e0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b7ef06d010c9ba77d0ffcbae9917b2f4c607f8ad Author: Paul Greenwalt Date: Wed Apr 8 16:11:05 2026 +0200 ice: fix ice_init_link() error return preventing probe commit eb509638686b0f8a98a0dd9c809f6a8db4d73a45 upstream. ice_init_link() can return an error status from ice_update_link_info() or ice_init_phy_user_cfg(), causing probe to fail. An incorrect NVM update procedure can result in link/PHY errors, and the recommended resolution is to update the NVM using the correct procedure. If the driver fails probe due to link errors, the user cannot update the NVM to recover. The link/PHY errors logged are non-fatal: they are already annotated as 'not a fatal error if this fails'. Since none of the errors inside ice_init_link() should prevent probe from completing, convert it to void and remove the error check in the caller. All failures are already logged; callers have no meaningful recovery path for link init errors. Fixes: 5b246e533d01 ("ice: split probe into smaller functions") Cc: stable@vger.kernel.org Signed-off-by: Paul Greenwalt Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 35176f104612e4f93a1ebefc65a9c5e8e23a0341 Author: Pei Xiao Date: Fri Jul 10 15:21:13 2026 +0800 i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED commit 9db20d23aac7916ff49be409a4bfd48fe7cbbfb4 upstream. When the interrupt status register reads zero, the handler should return IRQ_NONE instead of IRQ_HANDLED. What the return value actually feeds into is the spurious interrupt accounting in note_interrupt(): falsely claiming IRQ_HANDLED defeats the "irq XX: nobody cared" detection, so a stuck interrupt source would never be caught. Fixes: 5ea558473fa3 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Pei Xiao Cc: # v6.15+ Reviewed-by: Troy Mitchell Reviewed-by: Mukesh Savaliya Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/ef8b623f45d4e430721e46572c2598d882044aed.1783667875.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit fb267770bf822064f510c9b46743f533d8fa8a5f Author: Xuanqiang Luo Date: Tue Jul 14 23:08:08 2026 +0800 i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() commit 71356737a7a55c76fee847563e3d33f8e6dc6b6d upstream. If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res. Fixes: b5b5b32081cd ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Signed-off-by: Xuanqiang Luo Cc: # v5.10+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260714150808.85045-1-xuanqiang.luo@linux.dev Signed-off-by: Greg Kroah-Hartman commit bbc08be46f00222474ddf4f902c624a7830d7de7 Author: Roman Vivchar Date: Thu Jul 9 16:31:29 2026 +0300 i2c: mediatek: fix WRRD for SoCs without auto_restart option commit deb35336b5bfed5db9231b5348bc1514db930797 upstream. MediaTek mt65xx family SoCs have no auto restart, however, they still support the WRRD mode in the hardware. Because auto_restart is set to 0, the WRRD mode will be never enabled, leading to read errors. Fix this by removing auto_restart check from the WRRD enable path. Fixes: b49218365280 ("i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD") Signed-off-by: Roman Vivchar Cc: # v6.18+ Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260709-6572-6595-i2c-v2-1-b2fb8510d1d3@protonmail.com Signed-off-by: Greg Kroah-Hartman commit 56ddfc18ea8f7d77747658892873eb632b2ed530 Author: Vincent Jardin Date: Mon Jul 13 20:12:00 2026 +0200 i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ) commit 07fd9385f0d87dff4b34f355f68adf701080cb24 upstream. SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the interrupt-driven block-read state machine rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle of this i2c controller. Accept count=0: NACK the in-flight dummy byte (TXAK) and set msg->len to 2 so i2c_imx_isr_read_continue() emits STOP via its normal last-byte path. The dummy byte is discarded; block-read callers only consume buf[0..count-1]. Reading I2DR has likewise already armed the next byte on the count > I2C_SMBUS_BLOCK_MAX error path, so NACK it (TXAK) before aborting with -EPROTO; otherwise the failing transfer's STOP cannot complete and the bus stays held. The atomic path regressed earlier (v3.16) and is fixed separately; this patch covers only the v6.13 state-machine rework. Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Signed-off-by: Vincent Jardin Cc: # v6.13+ Acked-by: Oleksij Rempel Acked-by: Carlos Song Reviewed-by: Stefan Eichenberger Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260713-for-upstream-i2c-lx2160-fix-v1-v3-2-073ac9e103a5@free.fr Signed-off-by: Greg Kroah-Hartman commit 60ed00d46616a9232e42ea7a3e3c0273d7cf7543 Author: Vincent Jardin Date: Mon Jul 13 20:11:59 2026 +0200 i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) commit cb2fc37857693b55909fb77dc2c87cfbc1cdc476 upstream. SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range. Fixes: 8e8782c71595 ("i2c: imx: add SMBus block read support") Signed-off-by: Vincent Jardin Cc: # v3.16+ Acked-by: Oleksij Rempel Acked-by: Carlos Song Reviewed-by: Stefan Eichenberger Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260713-for-upstream-i2c-lx2160-fix-v1-v3-1-073ac9e103a5@free.fr Signed-off-by: Greg Kroah-Hartman commit c9a0f2bff2cb622c0f2a7534afaa5934a96c60dd Author: Joshua Crofts Date: Mon Jun 29 21:17:41 2026 +0200 hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig commit ed576f2f4eef8cbe2c110da503825a8dc4717030 upstream. The Kconfig entry for the MAX6697 sensor doesn't contain a `select REGMAP_I2C` parameter, causing build failures if regmap isn't selected previously during the build process. Fixes: 3a2a8cc3fe24 ("hwmon: (max6697) Convert to use regmap") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Link: https://lore.kernel.org/r/20260629-add-kconfig-deps-v1-3-8104df929b1a@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b9f07a4ec6e39ff2321046d4dcd245f88aef4fd9 Author: Joshua Crofts Date: Mon Jun 29 21:17:40 2026 +0200 hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig commit a35a6f1b20100057c66b7be5a8f6864661c3945c upstream. The Kconfig entry for the LTC2992 sensor doesn't contain a `select REGMAP_I2C` parameter, causing build failures if regmap isn't selected previously during the build process. Fixes: b0bd407e94b0 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Link: https://lore.kernel.org/r/20260629-add-kconfig-deps-v1-2-8104df929b1a@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a0d8e415ebf35e7ac28ea18c77ed00a9daef4925 Author: Ibrahim Hashimov Date: Thu Jul 9 17:05:30 2026 +0200 ksmbd: fix integer overflow in set_file_allocation_info() commit 1c0ae3df692ea2a4ce992f786346154e75a3f0d5 upstream. set_file_allocation_info() converts the client-supplied FILE_ALLOCATION_INFORMATION::AllocationSize into a 512-byte block count with: alloc_blks = (le64_to_cpu(file_alloc_info->AllocationSize) + 511) >> 9; AllocationSize is a fully client-controlled __le64 field; the only validation performed by the caller (smb2_set_info_file(), case FILE_ALLOCATION_INFORMATION) is that the fixed buffer is at least sizeof(struct smb2_file_alloc_info) == 8 bytes. The value itself is never range-checked before this arithmetic. When AllocationSize is close to U64_MAX (e.g. 0xffffffffffffffff), "AllocationSize + 511" wraps around mod 2^64 to a small number (0xffffffffffffffff + 511 = 510), so alloc_blks becomes 0. Since any existing regular file has stat.blocks > 0, the function then takes the "shrink" branch and calls: ksmbd_vfs_truncate(work, fp, alloc_blks * 512); /* == 0 */ silently truncating the file to size 0, even though the client asked to grow the allocation to (what looks like) the maximum possible size. The trailing "if (size < alloc_blks * 512) i_size_write(inode, size);" restore is guarded by a comparison that is never true once alloc_blks == 0, so the truncation is not undone. This lets an authenticated SMB client that already holds an open handle with FILE_WRITE_DATA on a file silently truncate that same file to size 0 via a single crafted SET_INFO(FILE_ALLOCATION_INFORMATION) request advertising a near-U64_MAX AllocationSize, even though the request asks to grow the file's allocation rather than shrink it. This is a functional/data-loss bug, not a privilege-boundary violation: the same client could already truncate the file via FILE_END_OF_FILE_INFORMATION or a plain write. Fix it by validating AllocationSize against MAX_LFS_FILESIZE, the same upper bound the VFS itself uses to reject unrepresentable file sizes, before doing the "+511" rounding, and rejecting oversized values with -EINVAL. Bounding AllocationSize to MAX_LFS_FILESIZE - 511 guarantees the "+511" addition cannot wrap, and that the subsequent "alloc_blks * 512" values passed to vfs_fallocate() and ksmbd_vfs_truncate() stay within a representable loff_t as well. No legitimate SMB client asks for an allocation size anywhere near 2^64 bytes, so this only rejects a value that was previously silently misinterpreted as zero. Runtime-verified on a v6.19 KASAN test stand: sending SET_INFO (FILE_ALLOCATION_INFORMATION) with AllocationSize = 0xffffffffffffffff against ksmbd now returns -EINVAL and leaves the target file's size unchanged, where the unpatched kernel truncated it from 4096 to 0 bytes. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c32f565f32919d9f5de3f2b27c5324358098edeb Author: Fredric Cover Date: Sat Jul 11 19:54:02 2026 -0700 smb: client: use kvzalloc() for megabyte buffer in simple fallocate commit 806c00c23e3ce8eae397a40ced536ef88ae4e012 upstream. Currently in smb3_simple_fallocate_range(), a 1 MB buffer is allocated using kzalloc(). Under heavy memory fragmentation, a contiguous 1 MB block of physical memory (an order-8 allocation) may not be available, causing the allocation to fail. This failure was observed during xfstests generic/013 on a 4GB RAM test machine running fsstress: fsstress: page allocation failure: order:8, mode:0x40dc0(GFP_KERNEL|__GFP_ZERO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 Call Trace: dump_stack_lvl+0x5d/0x80 warn_alloc+0x163/0x190 __alloc_pages_slowpath.constprop.0+0x71b/0x12f0 __alloc_frozen_pages_noprof+0x2f6/0x340 alloc_pages_mpol+0xb6/0x170 ___kmalloc_large_node+0xb3/0xd0 __kmalloc_large_noprof+0x1e/0xc0 smb3_simple_falloc.isra.0+0x62b/0x960 cifs_fallocate+0xed/0x180 vfs_fallocate+0x165/0x3c0 __x64_sys_fallocate+0x48/0xa0 do_syscall_64+0xe1/0x640 entry_SYSCALL_64_after_hwframe+0x76/0x7e Node 0 Normal: 3375*4kB ... 7*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB Since this scratch buffer does not require physically contiguous memory, switch the allocation to kvzalloc(). This retains the performance benefits of kmalloc() under normal conditions, while gracefully falling back to virtually contiguous memory when physical allocation fails. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Cc: stable@vger.kernel.org Signed-off-by: Fredric Cover Tested-by: Fredric Cover Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0bf6482919b9ce1fc7cf32521263ff1841495794 Author: Holger Dengler Date: Tue Jun 23 16:20:31 2026 +0200 pkey: Move keytype check from pkey api to handler commit 754e9e49b76fd5be339172aa98544182ed3ca75e upstream. The PKEY_VERIFYPROTK ioctl takes data from user-space and verifies the contained protected key. While checking the integrity of the ioctl request structure is the responsibility of the generic pkey_api code, the verification of the contained protected key is the responsibility of the pkey handler. The keytype verification (based on the calculated bitsize of the key) is part of the protected key verification and therefore the responsibility of the pkey handler (which already verifies it). Therefore the keytype verification is removed from the generic pkey_api code. As the calculation of the key bitsize is currently wrong, the removal of the keytype check in pkey_api also removes this wrong calculation. For this reason, the commit is flagged with the Fixes: tag. Cc: stable@kernel.org # 6.12+ Fixes: 8fcc231ce3be ("s390/pkey: Introduce pkey base with handler registry and handler modules") Reviewed-by: Ingo Franzki Reviewed-by: Harald Freudenberger Signed-off-by: Holger Dengler Signed-off-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 301bb780d1b9e61075331ec9f2636bed25be3e8d Author: Daniel Gibson Date: Thu Jun 11 17:04:26 2026 +0200 platform/x86/amd/pmc: Don't log during intermediate wakeups commit 037f0b03c663a247366673a807834389107995b7 upstream. The ECs in the IdeaPads that need the delay_suspend quirk send lots of messages when charging, which not only causes intermediate wakeups when suspended, but also prevents the device from reaching the deepest suspend state. Because of this amd_pmc_intermediate_wakeup_need_delay() returns false during intermediate wakeups and amd_pmc_want_suspend_delay() is called. So far it always logged its "Delaying suspend by 2.5s ..." messages then, which spams dmesg. This commit makes sure that those messages are only logged once per suspend. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383 Reviewed-by: Hans de Goede Signed-off-by: Daniel Gibson Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260611150426.3683372-5-daniel@gibson.sh Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit d53314ae31fd28e042aa4921c9057a7a018f7bea Author: Daniel Gibson Date: Thu Jun 11 17:04:25 2026 +0200 platform/x86/amd/pmc: Add delay_suspend module parameter commit 428b9fd2dce50b4dc5cd9ade10b92efcf57ce7aa upstream. Enabling the new delay_suspend module parameter delays suspend for 2.5 seconds which is known to help for some AMD-based Lenovo Laptops that otherwise failed to send/receive events for key presses or the lid switch after s2idle. Apparently the EC needs to do some things in the background before suspend or it gets into a bad state. There are many reports of AMD-based laptops (mostly but not exclusively IdeaPads) about similar issues on the web; this parameter gives affected users an easy way to try out if their issues have the same root cause and to work around them until their specific device is added to the quirks list. The parameter description has a note encouraging users to report their device so it can be added to the quirks list, inspired by a similar request in parameter descriptions of the ideapad-laptop module. The module parameter can be set to "1" to explicitly enable it, "0" to disable it even on devices that are assumed to be affected, or -1 (the default) to enable it if the device is assumed to be affected (according to fwbug_list[]) Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383 Reviewed-by: Hans de Goede Signed-off-by: Daniel Gibson Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260611150426.3683372-4-daniel@gibson.sh Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 675592e86e8122b3dc39ec79df282a9946025fc6 Author: Daniel Gibson Date: Thu Jun 11 17:04:24 2026 +0200 platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops commit 9b9e60dd31da054a37d601e9fcabdfd8a2bff354 upstream. Some IdeaPad Slim 3 devices and similar with AMD CPUs have a nonfunctional keyboard and lid switch after s2idle. It helps to delay suspend by 2.5 seconds so the EC has some time to do whatever it needs to get done before suspend - unfortunately at least on my 16ABR8 waking it with a timer (wakealarm) still triggers the issue, but at least normal resume via keypress or lid works fine. On the 14ARP10 wakealarm has been reported to also work fine with this patch. This issue has been reported for many different devices, this patch has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR) and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3 15ARP10 (83MM). Reported-by: Sindre Henriksen Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383 Tested-by: Sindre Henriksen Suggested-by: Mario Limonciello (AMD) Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Ilpo Järvinen Reviewed-by: Hans de Goede Signed-off-by: Daniel Gibson Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260611150426.3683372-3-daniel@gibson.sh Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 3002e2dda6216a238fde5f5b14e891827e0e00bf Author: Daniel Gibson Date: Thu Jun 11 17:04:23 2026 +0200 platform/x86/amd/pmc: Check for intermediate wakeup in function commit 3bdd6fc11fbfa8249483f4b716ead51e43e3a0cd upstream. Refactor code introduced by commit 9f5595d5f03f ("pmc: Require at least 2.5 seconds between HW sleep cycles") to allow adding different conditions for that delay in an upcoming change. Signed-off-by: Daniel Gibson Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260611150426.3683372-2-daniel@gibson.sh Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 2a42f651cce91e9cbe65fe933622c522cbb1868b Author: Srinivas Pandruvada Date: Thu May 28 13:45:21 2026 -0700 platform/x86: ISST: Restore SST-PP control to all domains commit 2565a28cdcdcb035e151d285efcba26bccb3726e upstream. The SST-PP control offset is only restored to power domain 0 after resume. During suspend, control values are read and stored for all power domains. Use pd_info->sst_base instead of power_domain_info->sst_base, which only points to power domain 0 base address. Fixes: dc7901b5a156 ("platform/x86: ISST: Store and restore all domains data") Reported-by: Yi Lai Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260528204521.3531456-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 14812174d720d83a79ed44ad0295a14cf40182a6 Author: Krishna Chomal Date: Mon Jun 8 19:12:55 2026 +0530 platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35) commit 56b7981c6f21670c0a1a62e6d2f9afb380e2596d upstream. The HP Omen 16-ap0xxx (board ID: 8E35) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_legacy_thermal_params. Testing on board 8E35 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Ahmet Öztürk Reported-by: Ahmet Öztürk Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221523 Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260608134255.36280-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 4676e81d55abb84a40d4ef9cd9e2eda7f6c1c719 Author: Krishna Chomal Date: Mon May 25 15:52:26 2026 +0530 platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26) commit 0aab31d47c2e857ca05028d718d1e0d239e683ad upstream. The HP Omen 16-ap0xxx (board ID: 8D26) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_legacy_thermal_params. Testing on board 8D26 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Alberto Escaño Reported-by: Alberto Escaño Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221514 Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260525102226.56300-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit b351e082711d12f075a36a6cd67709693689315f Author: Haoxiang Li Date: Tue Jun 9 16:14:19 2026 +0800 platform/x86: dell-laptop: fix missing cleanups in init error path commit 6e9cab2247e5b243ae2d907ce7c948a8a9c8d61a upstream. dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier. If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error. Add the missing cleanup calls before tearing down rfkill. Fixes: 9c656b07997f ("platform/x86: dell-*: Call new led hw_changed API on kbd brightness change") Fixes: 037accfa14b2 ("dell-laptop: Add debugfs support") Fixes: 2d8b90be4f1c ("dell-laptop: support Synaptics/Alps touchpad led") Fixes: 6cff8d60aa0a ("platform: x86: dell-laptop: Add support for keyboard backlight") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260609081419.1995169-1-lihaoxiang@isrc.iscas.ac.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 2137f21542900233a42bf00578817f9b8dfecadc Author: ZhaoJinming Date: Thu May 21 21:08:47 2026 +0800 platform/x86/intel/tpmi: use cleanup helpers in mem_write() commit a221557958e3a82d8565729d445a7385963f30b6 upstream. In mem_write(), the temporary array returned by parse_int_array_user() must be released on all exit paths. Convert the array variable to use cleanup.h scope-based cleanup so it is freed automatically on return. This also moves the array declaration next to parse_int_array_user() as required by cleanup.h usage guidelines. Fixes: 8e0a2fc68ec3 ("platform/x86/intel/tpmi: Use 32 bit aligned address for debugfs mem write") Cc: stable@vger.kernel.org Signed-off-by: ZhaoJinming Link: https://patch.msgid.link/20260521130848.2860219-1-zhaojinming@uniontech.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 07ae600bd353b22f31a8f1007269744fafc7f123 Author: Claudiu Beznea Date: Tue May 26 11:46:53 2026 +0300 dmaengine: sh: rz-dmac: Move interrupt request after everything is set up commit 731712403ddb39d1a76a11abf339a0615bc85de7 upstream. Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent(). Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Tested-by: John Madieu Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260526084710.3491480-2-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 044f7b3252d4fb2143d4999eec2800c08f1001ed Author: Koichiro Den Date: Thu May 21 23:21:51 2026 +0900 dmaengine: dw-edma-pcie: Reject devices without driver data commit 11d7cfe0c119691b2dafbb699bbca90258c678aa upstream. dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device. Fixes: 41aaff2a2ac0 ("dmaengine: Add Synopsys eDMA IP PCIe glue-logic") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Frank Li Link: https://patch.msgid.link/20260521142153.2957432-3-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 070b92cbb82acb22e748e438d1de6b4ec8749fb4 Author: Claudiu Beznea Date: Tue May 26 11:46:54 2026 +0300 dmaengine: sh: rz-dmac: Fix incorrect NULL check for list_first_entry() commit 5fbf3a2a3b96ef5810e6e0fbc601f82067629bc5 upstream. list_first_entry() does not return NULL when the list is empty, making the existing NULL check invalid. Use list_first_entry_or_null() instead. Fixes: 21323b118c16 ("dmaengine: sh: rz-dmac: Add device_tx_status() callback") Cc: stable@vger.kernel.org Tested-by: John Madieu Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260526084710.3491480-3-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 1553ca96e9df158d8f37137cf4bf5fb0dc981d94 Author: Frank Li Date: Thu May 21 23:21:53 2026 +0900 dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and ABORT_INT_MASK commit 8ffba0171c6bbce5f093c6dba5a02c0805b31203 upstream. The DONE_INT_MASK and ABORT_INT_MASK registers are shared by all DMA channels, and modifying them requires a read-modify-write sequence. Because this operation is not atomic, concurrent calls to dw_edma_v0_core_start() can introduce race conditions if two channels update these registers simultaneously. Add a spinlock to serialize access to these registers and prevent race conditions. Fixes: 7e4b8a4fbe2c ("dmaengine: Add Synopsys eDMA IP version 0 support") Cc: stable@vger.kernel.org Signed-off-by: Frank Li [den: update dw_edma.lock comment] Link: https://lore.kernel.org/dmaengine/20260109-edma_ll-v2-1-5c0b27b2c664@nxp.com/ Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260521142153.2957432-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 6e37e9e230c7e848bd8e8cd4db15bb18bcf11ad1 Author: Kartik Rajput Date: Wed Apr 22 12:11:34 2026 +0530 dmaengine: tegra: Fix burst size calculation commit 4651df83b6c796daead3447e8fd874322918ee4f upstream. Currently, the Tegra GPC DMA hardware requires the transfer length to be a multiple of the max burst size configured for the channel. When a client requests a transfer where the length is not evenly divisible by the configured max burst size, the DMA hangs with partial burst at the end. Fix this by reducing the burst size to the largest power-of-2 value that evenly divides the transfer length. For example, a 40-byte transfer with a 16-byte max burst will now use an 8-byte burst (40 / 8 = 5 complete bursts) instead of causing a hang. This issue was observed with the PL011 UART driver where TX DMA transfers of arbitrary lengths were stuck. Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput Reviewed-by: Frank Li Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260422064134.1323610-1-kkartik@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 7d3ce3bd23c062a7c1c6d372d1b08e48b9e17cc3 Author: Hongling Zeng Date: Wed Jun 3 09:36:52 2026 +0800 sunrpc: fix uninitialized xprt_create_args structure commit 17d90b68c3a3d7d7e95b49e1fe9381a723f637a8 upstream. The xprt_create_args structure is allocated on the stack without initialization in rpc_sysfs_xprt_switch_add_xprt_store(). While some fields are manually populated, critical fields like srcaddr, bc_xps, and flags contain uninitialized stack garbage. This can lead to: 1. Kernel panic when xs_setup_xprt() dereferences garbage srcaddr 2. Information leak if srcaddr points to sensitive stack data 3. Unpredictable behavior if flags has random bits set The fix is to zero-initialize the structure to ensure all unused fields are NULL/0, preventing the transport setup code from acting on garbage data. Cc: stable@vger.kernel.org Suggested-by: Jeff Layton Reviewed-by: Jeff Layton Signed-off-by: Hongling Zeng Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 493333f167926c7adab8e7563e21ad71d8af84fa Author: Michael Bommarito Date: Sun May 31 08:44:28 2026 -0400 tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt commit 73851a7c43dfa52d2ed9415889b33daf85da0ed9 upstream. tpm_buf_append_salt() in drivers/char/tpm/tpm2-sessions.c calls crypto_kpp_generate_public_key() and crypto_kpp_compute_shared_secret() without installing a completion callback, discards both return values, and immediately frees the kpp_request via kpp_request_free(). When the resolved ecdh-nist-p256 KPP backend is asynchronous (atmel-ecc, HPRE, keembay-ocs), either operation returns -EINPROGRESS and the deferred completion worker dereferences the freed request. The path fires automatically from the hwrng_fillfn kernel thread via tpm_get_random -> tpm2_get_random -> tpm2_start_auth_session -> tpm_buf_append_salt on every entropy poll, without any userland action. Install crypto_req_done as the completion callback, wrap both KPP operations in crypto_wait_req(), and propagate errors to the caller. The wait is a no-op for synchronous backends. Fixes: 1085b8276bb4 ("tpm: Add the rest of the session HMAC API") Cc: stable@vger.kernel.org # v6.10+ Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 4bb3e1bc142dc9c3240ceed1b3ab031aa9cb1723 Author: Jarkko Sakkinen Date: Sat May 9 21:51:07 2026 +0300 tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat() commit c0c9cfb3b75def8bf200a2d4db09015806acfeaf upstream. wait_event_interruptible_timeout() evaluates its condition after setting the current task state to TASK_INTERRUPTIBLE. With CONFIG_DEBUG_ATOMIC_SLEEP this triggers a warning when the IRQ wait path is used: tpm_tis_status() tpm_tis_spi_read_bytes() tpm_tis_spi_transfer_full() spi_bus_lock() mutex_lock() Address this with the following measures: 1. Call wait_tpm_stat_cond() only while tasking is running. 2. Use wait_woken() to wait for changes. Cc: stable@vger.kernel.org # v4.19+ Cc: Linus Walleij Reported-by: Stefan Wahren Closes: https://lore.kernel.org/linux-integrity/6964bec7-3dbb-453b-89ef-9b990217a8b9@gmx.net/ Fixes: 1a339b658d9d ("tpm_tis_spi: Pass the SPI IRQ down to the driver") Reviewed-by: Linus Walleij Tested-by: Stefan Wahren Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 711cbcb464d288254c958094ffd71ed17c089dc7 Author: Baoli Zhang Date: Tue Apr 21 08:50:20 2026 +0800 tpm: restore timeout for key creation commands commit de59d78e64039baa5fed455ddb905ba8263e7ede upstream. Commit 207696b17f38 ("tpm: use a map for tpm2_calc_ordinal_duration()") inadvertently reduced the timeout for TPM2 key creation commands (`CREATE_PRIMARY`, `CREATE`, `CREATE_LOADED`) from 300 seconds to 30 seconds. This causes intermittent timeout failures, with several failures observed across hundreds of test runs on some Intel platforms using Infineon SLB9670 and SLB9672 TPM modules. Restore the timeout to 300 seconds to avoid spurious failures. Cc: stable@vger.kernel.org # v6.18+ Fixes: 207696b17f38 ("tpm: use a map for tpm2_calc_ordinal_duration()") Co-developed-by: Lili Li Signed-off-by: Lili Li Signed-off-by: Baoli Zhang Link: https://lore.kernel.org/r/20260421005021.13765-1-baoli.zhang@linux.intel.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit e5be5d452d5f1efbb3342da2b00029be6c99034e Author: Bhargav Joshi Date: Sat Jun 20 17:39:16 2026 +0530 irqchip/crossbar: Use correct index in crossbar_domain_free() commit 043db005a8d6932dc7d217c86307e9af0bc10ddc upstream. crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data. Fixes: 783d31863fb82 ("irqchip: crossbar: Convert dra7 crossbar to stacked domains") Signed-off-by: Bhargav Joshi Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260620-irq-crossbar-fix-v2-1-b8e8499f468a@gmail.com Signed-off-by: Greg Kroah-Hartman commit c267911b4226a3f6e7987fd9ee2d38719bb065bf Author: Yiyang Chen Date: Mon Apr 13 23:45:44 2026 +0800 taskstats: retain dead thread stats in TGID queries commit b3e4fbb04220efc3bc022bcf31b5689d39c6b111 upstream. Patch series "taskstats: fix TGID dead-thread stat retention", v3. This series fixes a taskstats TGID aggregation bug where fields added in the TGID query path were not preserved after thread exit, and adds a kselftest covering the regression. The first patch keeps the cached TGID aggregate used for dead threads in step with the fields already accumulated for live threads, and also fixes the final TGID exit notification emitted when group_dead is true. The second patch adds a kselftest that verifies TGID CPU stats do not regress after a worker thread exits and has been reaped. This patch (of 2): fill_stats_for_tgid() builds TGID stats from two sources: the cached aggregate in signal->stats and a scan of the live threads in the group. However, fill_tgid_exit() only accumulates delay accounting into signal->stats. This means that once a thread exits, TGID queries lose the fields that fill_stats_for_tgid() adds for live threads. This gap was introduced incrementally by two earlier changes that extended fill_stats_for_tgid() but did not make the corresponding update to fill_tgid_exit(): - commit 8c733420bdd5 ("taskstats: add e/u/stime for TGID command") added ac_etime, ac_utime, and ac_stime to the TGID query path. - commit b663a79c1915 ("taskstats: add context-switch counters") added nvcsw and nivcsw to the TGID query path. As a result, those fields were accounted for live threads in TGID queries, but were dropped from the cached TGID aggregate after thread exit. The final TGID exit notification emitted when group_dead is true also copies that cached aggregate, so it loses the same fields. Factor the per-task TGID accumulation into tgid_stats_add_task() and use it in both fill_stats_for_tgid() and fill_tgid_exit(). This keeps the cached aggregate used for dead threads aligned with the live-thread accumulation used by TGID queries. Link: https://lore.kernel.org/cover.1776094300.git.cyyzero16@gmail.com Link: https://lore.kernel.org/abd2a15d33343636ab5ba43d540bcfe508bd66c7.1776094300.git.cyyzero16@gmail.com Fixes: 8c733420bdd5 ("taskstats: add e/u/stime for TGID command") Fixes: b663a79c1915 ("taskstats: add context-switch counters") Signed-off-by: Yiyang Chen Acked-by: Balbir Singh Cc: Dr. Thomas Orgis Cc: Oleg Nesterov Cc: Wang Yaxin Cc: Yang Yang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f4599793240dd60a0a708ef1fe116223f47aa105 Author: Florian Fuchs Date: Mon May 18 13:45:21 2026 +0200 mtd: maps: vmu-flash: fix NULL pointer dereference in initialization commit 357e3b8e3a8769ba36eb8ec5e053e4825f1a9329 upstream. The mtd_info contains a struct device, which must be linked to its parent. Without this, the initialization of the MTD fails with a NULL pointer dereference. Fixes: 47a72688fae7 ("mtd: flash mapping support for Dreamcast VMU.") Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 57740658042daf591c57d6e700d9a304d5972552 Author: Stafford Horne Date: Fri May 22 17:28:31 2026 +0100 openrisc: Fix jump_label smp syncing commit aca063c9024522e4e5b9a9d1927433f6a01785a3 upstream. The original commit 8c30b0018f9d ("openrisc: Add jump label support") copies from arm64 and does not properly consider how icache invalidation on remote cores works in OpenRISC. On OpenRISC remote icaches need to be invalidated otherwise static key's may remain state after updating. Fix SMP cache syncing by: 1. Properly invalidate remote core icaches on SMP systems by using icache_all_inv. The old code uses kick_all_cpus_sync() which runs a no-op IPI function call on remote CPU's which does execute a lot of code and flushes many cache lines in the process, but does not flush all and it's not correct on OpenRISC. 2. For architectures that do not have WRITETHROUGH caches be sure to flush the dcache after patching. To test this I first reproduced the issue using a custom test module [0]. The test confirmed that some icache lines maintained stale static_key code sequences after calling static_branch_enable(). After this patch there are no longer jump_label coherency issues. [0] https://github.com/stffrdhrn/or1k-utils/tree/master/tests/smp_static_key_test Cc: stable@vger.kernel.org # depends on openrisc: Add icache_all_inv Fixes: 8c30b0018f9d ("openrisc: Add jump label support") Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit a145b47e22fdff38e475c5e3159de3ed086dece8 Author: Miquel Raynal Date: Fri May 22 11:17:39 2026 +0200 mtd: rawnand: Pause continuous reads at block boundaries commit 8e4531667d718e2e9b193928cf9b2497fa0d01ef upstream. Some chips do not support sequential cached reads past block boundaries, like Winbond. In practice when using UBI, this should very rarely happen, but let's make sure it never happens. Cc: stable@vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 007e28b2916d07b2a9a608d94c421d944d7b76aa Author: Takahiro Kuwano Date: Wed May 27 18:05:39 2026 +0900 mtd: spi-nor: spansion: use die erase for multi-die devices only commit 306e443156b82a2a14a3f33da908c303be45529c upstream. Die erase opcode is supported in multi-die devices only. For single die devices, default chip erase opcode must be used. In s25hx_t_late_init(), die erase opcode is set only when the device is multi-die. Fixes: 461d0babb544 ("mtd: spi-nor: spansion: enable die erase for multi die flashes") Cc: stable@kernel.org Reviewed-by: Pratyush Yadav Reviewed-by: Tudor Ambarus Reviewed-by: Miquel Raynal Signed-off-by: Takahiro Kuwano Reviewed-by: Michael Walle Signed-off-by: Pratyush Yadav Signed-off-by: Greg Kroah-Hartman commit 12d4d69221159e6d0e72400ec81195d691169b53 Author: Miquel Raynal Date: Tue May 26 16:56:26 2026 +0200 mtd: spi-nor: swp: Improve locking user experience commit e1d456b26bf23e30db305a6184e8abd9ab68bbf2 upstream. In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails. It fails because the conditions "can_be_top" and "can_be_bottom" are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to "nor->params->size - (ofs + len)" which is a positive number. This is wrong. An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic. Fixes: 3dd8012a8eeb ("mtd: spi-nor: add TB (Top/Bottom) protect support") Cc: stable@kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Michael Walle Signed-off-by: Pratyush Yadav Signed-off-by: Greg Kroah-Hartman commit 614aa0491c7a190556c2345dddee0b6f5ed90989 Author: Holger Dengler Date: Wed Jun 17 19:06:39 2026 +0200 s390/pkey: Check length in pkey_pckmo handler implementation commit 1ac287e2af9a9112fe271427ef45eceb26bce8b4 upstream. Explicitly check the length of the target buffer in the pkey_pckmo implementation of the key_to_protkey() handler function. The handler function fails, if the generated output data exceeds the length of the provided target buffer. Cc: stable@vger.kernel.org Fixes: 8fcc231ce3be ("s390/pkey: Introduce pkey base with handler registry and handler modules") Reported-by: Christian Borntraeger Reviewed-by: Harald Freudenberger Signed-off-by: Holger Dengler Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit 7e7e03848c918aa0acad5ffd75d929e3afec1554 Author: Holger Dengler Date: Mon Jun 15 17:39:12 2026 +0200 s390/pkey: Check length in PKEY_VERIFYPROTK ioctl commit b3d4ab2d7df9426f7f1d3671d7e2108f2ca6e970 upstream. Explicitly check the buffer length request structure provided by user-space and fail, if it exceeds the buffer size. Cc: stable@vger.kernel.org Fixes: 8fcc231ce3be ("s390/pkey: Introduce pkey base with handler registry and handler modules") Reported-by: Christian Borntraeger Reviewed-by: Harald Freudenberger Reviewed-by: Ingo Franzki Signed-off-by: Holger Dengler Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit 3da8eaf5469eda2353b72038d644fabddb848ce1 Author: Sebastian Alba Vives Date: Mon May 18 13:07:42 2026 -0600 fpga: microchip-spi: fix zero header_size OOB read in mpf_ops_parse_header() commit 43a1974da6bc7ce8f4d1dc1d03d56997428c29c3 upstream. mpf_ops_parse_header() reads header_size from the bitstream at MPF_HEADER_SIZE_OFFSET (24). When header_size is zero, the expression *(buf + header_size - 1) reads one byte before the buffer start. Since initial_header_size is set to 71 in mpf_ops, the fpga-mgr core guarantees the buffer is large enough to reach MPF_HEADER_SIZE_OFFSET. The only real gap is the zero header_size case, which cannot be resolved by providing a larger buffer, so return -EINVAL. Fixes: 5f8d4a900830 ("fpga: microchip-spi: add Microchip MPF FPGA manager") Cc: stable@vger.kernel.org Signed-off-by: Sebastian Alba Vives Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260518190742.61426-4-sebasjosue84@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit fe6b606fbf0c3beb94ccf17fcf31d8c2138264e3 Author: Maoyi Xie Date: Wed Jun 17 01:38:41 2026 +0800 net: thunderbolt: Fix frags[] overflow by bounding frame_count commit 55d9895f89970501fe126d1026b586b04a224c27 upstream. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, hdr_size, frame_size, TBNET_RX_PAGE_SIZE - hdr_size); A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info. Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never produce more fragments than frags[] can hold. This matches the recent skb frags overflow fixes in other receive paths, for example f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") and 600dc40554dc ("net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()"). Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Acked-by: Mika Westerberg Link: https://patch.msgid.link/178163152194.2486768.14724194232649760778@maoyixie.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4f6542b1428893a64b7477e64d9c518c6c8f0003 Author: Manivannan Sadhasivam Date: Mon Mar 2 14:26:12 2026 +0530 bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path commit 519ddf194b158b91439319f6b977b8a465fda0fb upstream. All the callers of mhi_ep_handle_syserr() except mhi_ep_process_cmd_ring() are holding the 'state_lock' to avoid the race in setting the MHI state. So do the same in mhi_ep_process_cmd_ring() for sanity. Fixes: e827569062a8 ("bus: mhi: ep: Add support for processing command rings") Cc: stable@vger.kernel.org # 5.18 Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260302085612.18725-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit e0578493c950e155149560afc69e7048a8da67ce Author: Manivannan Sadhasivam Date: Wed May 27 10:46:13 2026 +0200 bus: mhi: host: pci_generic: Fix the physical function check commit 32845111e8ea6ef5e837b6d25080e69e99bd4561 upstream. Commit b4d01c5b9a9d ("bus: mhi: host: pci_generic: Read SUBSYSTEM_VENDOR_ID for VF's to check status") added the check for physical function by checking for 'pdev->is_physfn. But 'pdev->is_physfn' is only set for the physical function of a SR-IOV capable device. But for the non-SR-IOV device this variable will be 0. So this check ended up breaking the health check functionality for all non-SR-IOV devices. Fix it by checking for '!pdev->is_virtfn' to make sure that the check is only skipped for virtual functions. Cc: stable@vger.kernel.org # 6.18 Reported-by: Slark Xiao Tested-by: Slark Xiao Fixes: b4d01c5b9a9d ("bus: mhi: host: pci_generic: Read SUBSYSTEM_VENDOR_ID for VF's to check status") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit f3df5386e3bb54626c117bd85e0158d45fb4aea9 Author: Sebastian Alba Vives Date: Mon May 18 13:07:40 2026 -0600 fpga: dfl: add bounds check in dfh_get_param_size() commit 9e8bc49f91f3f81d957c4f1c1f09fe94e2f88f6a upstream. dfh_get_param_size() can return a parameter size larger than the feature region because the loop bounds check is evaluated before incrementing size. If the EOP (End of Parameters) bit is set in the same iteration, the inflated size is returned without re-validation against max. This can cause create_feature_instance() to call memcpy_fromio() with a size exceeding the ioremap'd region when a malicious FPGA device provides crafted DFHv1 parameter headers. Add a bounds check after the size increment to ensure the accumulated size never exceeds the feature boundary. Fixes: 4747ab89b4a6 ("fpga: dfl: add basic support for DFHv1") Cc: stable@vger.kernel.org Signed-off-by: Sebastian Alba Vives Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260518190742.61426-2-sebasjosue84@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit 3bfeb436d4be6a2beb56cab344770e93e6b07260 Author: Michael Bommarito Date: Tue May 19 07:04:04 2026 -0400 ocfs2: reject non-inline dinodes with i_size and zero i_clusters commit 7ebc672fab7a76e1e47e0f2fc1ee48118d27fde4 upstream. On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode(). Link: https://lore.kernel.org/20260519110404.1803902-4-michael.bommarito@gmail.com Fixes: b657c95c1108 ("ocfs2: Wrap inode block reads in a dedicated function.") Signed-off-by: Michael Bommarito Link: https://sashiko.dev/#/patchset/20260517111015.3187935-1-michael.bommarito%40gmail.com Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 60ceecda550e3d9683fb4b7604b36a014ae044cd Author: Michael Bommarito Date: Tue May 19 07:04:03 2026 -0400 ocfs2: reject dinodes whose i_rdev disagrees with the file type commit 51407c2d249987a466416890a5c931a2354a46aa upstream. id1.dev1.i_rdev is the device-number arm of the ocfs2_dinode id1 union. It is only meaningful for character and block device inodes. For any other user-visible file type the on-disk value must be zero. ocfs2_populate_inode() currently copies id1.dev1.i_rdev into inode->i_rdev before the S_IFMT switch decides whether the inode is a special file. A non-device inode with a non-zero i_rdev can therefore publish stale or attacker-controlled device state into the in-core inode. System inodes legitimately use other arms of the same union, so keep the cross-check restricted to non-system inodes. Factor that predicate into a helper and use it in both the normal validator and online filecheck path; filecheck reports the malformed dinode through OCFS2_FILECHECK_ERR_INVALIDINO instead of ocfs2_error(). Link: https://lore.kernel.org/20260519110404.1803902-3-michael.bommarito@gmail.com Fixes: b657c95c1108 ("ocfs2: Wrap inode block reads in a dedicated function.") Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b858f2d57cfc9d57ce61b86051d603dc0ebccd40 Author: Michael Bommarito Date: Tue May 19 07:04:02 2026 -0400 ocfs2: reject dinodes with non-canonical i_mode type commit 5366a017099c6a3c443be908a05f26fd72af12a1 upstream. Patch series "ocfs2: harden inode validators against forged metadata", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode(). Link: https://lore.kernel.org/20260519110404.1803902-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/20260519110404.1803902-2-michael.bommarito@gmail.com Fixes: b657c95c1108 ("ocfs2: Wrap inode block reads in a dedicated function.") Signed-off-by: Michael Bommarito Link: https://sashiko.dev/#/patchset/20260517111015.3187935-1-michael.bommarito%40gmail.com Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 63921f790234b221e4b15c56c72888b13250f81d Author: Joseph Qi Date: Sun May 31 21:16:45 2026 +0800 ocfs2: add journal NULL check in ocfs2_checkpoint_inode() commit a291c77c034b7a81849ce9b71cc9ecda9e587d89 upstream. During unmount, ocfs2_journal_shutdown() frees the journal and sets osb->journal to NULL. Later, when VFS evicts remaining cached inodes, ocfs2_evict_inode() -> ocfs2_clear_inode() -> ocfs2_checkpoint_inode() -> ocfs2_ci_fully_checkpointed() dereferences osb->journal, causing a NULL pointer dereference. Fix this by adding a NULL check for osb->journal in ocfs2_checkpoint_inode(). If the journal is NULL, it has already been fully flushed and destroyed during shutdown, so there is nothing to checkpoint. Link: https://lore.kernel.org/20260531131645.3650299-1-joseph.qi@linux.alibaba.com Reported-by: Farhad Alemi Fixes: da5e7c87827e ("ocfs2: cleanup journal init and shutdown") Signed-off-by: Joseph Qi Tested-by: Farhad Alemi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 858aa4965ffa8c0d4bb5dd835ac4f1c9a1dcab85 Author: Ian Bridges Date: Wed Jun 10 19:23:11 2026 -0500 ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec commit 452a8467be8143747292218212671deeb186d2ae upstream. [BUG] On-disk corruption setting l_next_free_rec to 0 in an inode's embedded extent list triggers a UBSAN panic on the next write to that file. [CAUSE] ocfs2_sum_rightmost_rec() computes i = le16_to_cpu(el->l_next_free_rec) - 1 and accesses el->l_recs[i] without validating i. When l_next_free_rec is 0, i becomes -1; when l_next_free_rec exceeds l_count, i falls past the end of the array. Either case violates the __counted_by_le(l_count) annotation on l_recs[] and triggers UBSAN. [FIX] Validate the inode's embedded extent list when the inode is read, in ocfs2_validate_inode_block(): l_count must be non-zero and no larger than the inode block can hold, and l_next_free_rec must not exceed l_count. A corrupt list is rejected at read time, before the b-tree code can index l_recs[] out of bounds. Link: https://lore.kernel.org/ain_780qc0P4ypNd@dev Signed-off-by: Ian Bridges Reported-by: syzbot+be16e33db01e6644db7a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=be16e33db01e6644db7a Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 253ed993e0b36997ec7b04c1ff76103b38241de2 Author: Ian Bridges Date: Thu Jun 11 09:46:38 2026 -0500 ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits commit f9ab30c96b0f00c20c6dac93681bdae3a033d229 upstream. [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted. Link: https://lore.kernel.org/airKTsM1fRVN-Wj7@dev Fixes: be346c1a6eeb ("ocfs2: fix DIO failure due to insufficient transaction credits") Signed-off-by: Ian Bridges Reported-by: syzbot+e9c15ff790cea6a0cfae@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e9c15ff790cea6a0cfae Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4d1953d3aeb4a7f6623083e1839068ee1c157db2 Author: Kyle Zeng Date: Thu Jun 11 14:35:10 2026 -0700 ocfs2: avoid moving extents to occupied clusters commit 22920541c35a9f23f219038ba5874c843a7c4419 upstream. For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal. Link: https://lore.kernel.org/20260611213510.16956-1-kylebot@openai.com Fixes: e6b5859cccfa ("Ocfs2/move_extents: helper to probe a proper region to move in an alloc group.") Fixes: 236b9254f8d1 ("ocfs2: fix non-auto defrag path not working issue") Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8f575fc17360827ca1d1940a84f3c7ee40407a10 Author: Arseniy Krasnov Date: Tue May 5 11:30:30 2026 +0300 mtd: rawnand: fix condition in 'nand_select_target()' commit 8507c2cc9e4fa402401819f44d1e8a5ef4d11d8b upstream. 'cs' here must be in range [0:nanddev_ntargets[. Cc: stable@vger.kernel.org Fixes: 32813e288414 ("mtd: rawnand: Get rid of chip->numchips") Signed-off-by: Arseniy Krasnov Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 823886a1b089b49bcd349bc8bd3417b7910cd1ac Author: Vasiliy Kovalev Date: Wed Apr 15 18:52:37 2026 +0300 net/9p: fix infinite loop in p9_client_rpc on fatal signal commit 6b4f48728faa8bb514368f7eacda05565dea8696 upstream. When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: err = io_wait_event_killable(req->wq, ...) /* SIGKILL wakes the task, returns -ERESTARTSYS */ if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; } clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 91b8534fa8f5 ("9p: make rpc code common and rework flush code") Closes: https://syzkaller.appspot.com/bug?extid=3ce7863f8fc836a427e7 Cc: stable@vger.kernel.org Signed-off-by: Vasiliy Kovalev Message-ID: <20260415155237.182891-1-kovalev@altlinux.org> Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 3c44f6c62f652d3ac9d03beb8a199e6388256cdd Author: Bastien Curutchet Date: Tue May 26 09:10:00 2026 +0200 mtd: rawnand: pl353: fix probe resource allocation commit 19ed11aee966d91beebdef9d32ce926474872f79 upstream. During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent. Cc: stable@vger.kernel.org Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Bastien Curutchet Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 20869525a283c2cd5d2f467bca6d0009b6e42f15 Author: Tristan Madani Date: Sat Apr 18 13:10:48 2026 +0000 ocfs2: use kzalloc for quota recovery bitmap allocation commit 93c8c6ea90be9e9df8fe14048ad4e3caad0770a6 upstream. ocfs2 quota recovery allocates a bitmap buffer with kmalloc and does not fully initialize it. This can lead to use of uninitialized bits during quota recovery from a corrupted filesystem image. Use kzalloc instead to ensure the bitmap is zero-initialized. Link: https://lore.kernel.org/20260418131048.1052507-1-tristmd@gmail.com Reported-by: syzbot+7ea0b96c4ddb49fd1a70@syzkaller.appspotmail.com Signed-off-by: Tristan Madani Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 455519f6b70f46ac6cbf41a75ac76ec5e59040f2 Author: Florian Fuchs Date: Mon May 18 13:45:20 2026 +0200 mtd: maps: vmu-flash: fix fault in unaligned fixup commit 79d1661502c6e4b6f626185cef72cf2fa78116e1 upstream. Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info. Fixes: 47a72688fae7 ("mtd: flash mapping support for Dreamcast VMU.") Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 9f457beb601d1bfaa0fe57f53543a00fed92d6a0 Author: Stafford Horne Date: Fri May 22 16:56:03 2026 +0100 openrisc: Add full instruction cache invalidate functions commit 1be031de802ba486a7605b52eda825f128b026e2 upstream. Add functions to invalidate all cache lines which we will use for static_key patching. On OpenRISC there is no instruction to invalidate an entire cache so we loop and invalidate cache lines one by one. This is not extremely expensive on OpenRISC as we usually have only a few hundred cache lines. I considered using the invalidate cache page or range functions. However, tracking which ranges need invalidation would have been more expensive than flushing all pages. Cc: stable@vger.kernel.org Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit c8f8e61332ba72d50e2dda9d09abe1e89bc2eed3 Author: Ionut Nechita Date: Tue May 19 16:52:33 2026 +0300 scsi: sas: Skip opt_sectors when DMA reports no real optimization hint commit be8fcd4a8217a916344c88a4b1b84f5736dda17e upstream. sas_host_setup() unconditionally sets shost->opt_sectors from dma_opt_mapping_size(). When the IOMMU is disabled or in passthrough mode and no DMA ops provide an opt_mapping_size callback, dma_opt_mapping_size() returns min(dma_max_mapping_size(), SIZE_MAX) which equals dma_max_mapping_size() — a hard upper bound, not an optimization hint. On a Dell PowerEdge R750 with mpt3sas (Broadcom SAS3816, FW 33.15.00.00) and intel_iommu=off the following values are observed: dma_opt_mapping_size() = dma_max_mapping_size() (no real hint) shost->max_sectors = 32767 opt_sectors = min(32767, huge >> 9) = 32767 optimal_io_size = 32767 << 9 = 16776704 → round_down(16776704, 4096) = 16773120 The SAS disk (SAMSUNG MZILT800HBHQ0D3) does not report an Optimal Transfer Length in VPD page B0, so sdkp->opt_xfer_blocks remains 0. sd_revalidate_disk() then uses min_not_zero(0, opt_sectors) = opt_sectors, propagating the bogus value into the block device's optimal_io_size (visible as OPT-IO = 16773120 in lsblk --topology). mkfs.xfs picks up optimal_io_size and minimum_io_size and computes: swidth = 16773120 / 4096 = 4095 sunit = 8192 / 4096 = 2 Since 4095 % 2 != 0, XFS rejects the geometry: SB stripe unit sanity check failed This makes it impossible to create XFS filesystems (e.g. for /var/lib/docker) during system bootstrap. Fix this by introducing a sas_dma_setup_opt_sectors() helper that sets opt_sectors only when dma_opt_mapping_size() is strictly less than dma_max_mapping_size(), indicating a genuine DMA optimization constraint. The helper computes min(opt_sectors, max_sectors) first, then rounds down to a power of two so that filesystem geometry calculations always produce clean results. When the two DMA values are equal, no backend provided a real hint, so opt_sectors stays at 0 ("no preference"). [mkp: implemented hch's suggestion] Fixes: 4cbfca5f7750 ("scsi: scsi_transport_sas: cap shost opt_sectors according to DMA optimal limit") Cc: stable@vger.kernel.org Reviewed-by: John Garry Signed-off-by: Ionut Nechita Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260519135238.373784-2-ionut.nechita@windriver.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9fefab759f59bf891bef7be15aee4bc7caec7ec3 Author: Pratyush Yadav (Google) Date: Tue May 19 18:05:49 2026 +0200 kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES commit 0e39380a7316122e1b00012b3f3cd3e318b3e7d3 upstream. When using scratch_scale, the scratch sizes are rounded up to CMA_MIN_ALIGNMENT_BYTES since they will be released as MIGRATE_CMA. This is not done when using fixed scratch sizes via command line. This can result in user specifying a size which is not aligned, and thus kernel releasing a pageblock that is only partially scratch. Do the rounding up for both cases in scratch_size_update(). Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers") Cc: stable@kernel.org Signed-off-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260519160554.2713361-1-pratyush@kernel.org Signed-off-by: Pasha Tatashin Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Greg Kroah-Hartman commit d52d4c9ac716a671cf2a1f85a52a1548aebedab3 Author: Martin Wilck Date: Wed May 13 19:42:35 2026 +0200 scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished() commit 57db1307afb1f83d45f5ff53b93f8d040100d13e upstream. shost_to_hba() is used everywhere except to obtain pqi_ctrl_info from shosti, except in pqi_scan_finished(), where shost_priv() is used. This causes one pointer dereference to be missed, as shost->hostdata is a pointer in smartpqi. Fix it. Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver") Signed-off-by: Martin Wilck Reviewed-by: Don Brace Cc: Don Brace Cc: storagedev@microchip.com Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260513174236.430465-2-mwilck@suse.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 8c1b23d830087287b3cef2eb899ec6282f53c378 Author: Alexey Charkov Date: Wed Jun 3 00:10:50 2026 +0400 power: supply: bq257xx: Fix VSYSMIN clamping logic commit b6c6b9260a92dacef6edef8e93bc2767b86b1dfe upstream. The minimal system voltage (VSYSMIN) is meant to protect the battery from dangerous over-discharge. When the device tree provides a value for the minimum design voltage of the battery, the user should not be allowed to set a lower VSYSMIN, as that would defeat the purpose of this protection. Flip the clamping logic when setting VSYSMIN to ensure that battery design voltage is respected. Cc: stable@vger.kernel.org Fixes: 1cc017b7f9c7 ("power: supply: bq257xx: Add support for BQ257XX charger") Tested-by: Chris Morgan Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260603-bq25792-v7-2-d487bed276d0@flipper.net Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 8faccac11e1369adddf5d80f4a45af93f13b2e1a Author: Breno Leitao Date: Tue Apr 21 02:41:09 2026 -0700 9p: skip nlink update in cacheless mode to fix WARN_ON commit 574aa0b4799470ac814479f1138d19efe6262255 upstream. v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode's nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value: 1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client's v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0 This race is easily triggered under heavy unlink workloads, such as stress-ng's unlink stressor, producing the following warning: WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink > 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close. Fixes: ac89b2ef9b55 ("9p: don't maintain dir i_nlink if the exported fs doesn't either") Cc: stable@vger.kernel.org Suggested-by: Dominique Martinet Signed-off-by: Breno Leitao Message-ID: <20260421-9p-v2-1-48762d294fad@debian.org> Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit bdcdfc2464659789032edfad15ff5f7a166f5d7b Author: Ruoyu Wang Date: Tue Jun 9 16:45:27 2026 +0800 mtd: slram: remove failed entries from the device list commit 36f1648644d769c496a8e47e53603e863e358d73 upstream. register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 3afd3929fbc794961b87ef826134dfdfae808033 Author: Karl Mehltretter Date: Tue May 26 13:47:15 2026 +0200 kcov: use WRITE_ONCE() for selftest mode stores commit 9a79524d1420e6b79a6868208c264f4518d1318e upstream. The KCOV selftest enables coverage by setting current->kcov_mode to KCOV_MODE_TRACE_PC without installing a coverage area. If an interrupt records coverage in that window, the access should fault and expose the bug. When building for QEMU raspi0 (Raspberry Pi Zero, ARMv6, CONFIG_CPU_V6K=y, CONFIG_CURRENT_POINTER_IN_TPIDRURO=y) with GCC 13.3.0, the store that enables the mode is removed. The generated kcov_init() code only stores zero after the wait loop: mrc 15, 0, r3, cr13, cr0, {3} str r4, [r3, #2028] where r4 is zero. There is no store of KCOV_MODE_TRACE_PC before the loop, so the selftest reports success without exercising coverage. Use WRITE_ONCE() for the temporary mode stores. With the same compiler and config, kcov_init() contains the intended mode store: mov r3, #2 mrc 15, 0, r2, cr13, cr0, {3} str r3, [r2, #2028] Now that the KCOV selftest is actually executed, it may expose KCOV instrumentation issues depending on the kernel config. That is expected for a selftest that was intended to catch coverage from interrupt paths. Link: https://lore.kernel.org/20260526114715.38280-1-kmehltretter@gmail.com Fixes: 6cd0dd934b03 ("kcov: Add interrupt handling self test") Assisted-by: Codex:gpt-5 Signed-off-by: Karl Mehltretter Reviewed-by: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Kees Cook Cc: Marco Elver Cc: Peter Zijlstra Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b91e27bce37cab9f35de0059278ebe457ca9878b Author: Muchun Song Date: Tue Apr 28 16:18:55 2026 +0800 mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE commit cd681403a87085562499d60325b7b45d3be11217 upstream. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize. Link: https://lore.kernel.org/20260428081855.1249045-7-songmuchun@bytedance.com Fixes: 6fd3620b3428 ("mm/page_alloc: reuse tail struct pages for compound devmaps") Signed-off-by: Muchun Song Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Acked-by: Liam R. Howlett Cc: "Aneesh Kumar K.V" Cc: Joao Martins Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Michal Hocko Cc: Nicholas Piggin Cc: Oscar Salvador Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1712a7fa133924d91a7211dde206ca1892bf0a40 Author: Amit Machhiwal Date: Sun Jun 14 23:04:37 2026 +0530 powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later processors commit e4de1b9cb3b5c981e4fe9bca253a7fb9161f5acd upstream. When using device tree CPU features (dt-cpu-ftrs), the kernel bypasses the traditional cputable-based CPU identification and instead derives CPU features from the device tree's "ibm,powerpc-cpu-features" node provided by firmware. However, CPU_FTR_P11_PVR is a kernel-internal feature flag used to identify Power11 and later processors, and is not represented in the device tree's ISA feature set. While ISA v3.1 support (indicated by CPU_FTR_ARCH_31) is present on both Power10 and Power11, the CPU_FTR_P11_PVR flag is specifically needed by code that must distinguish between Power10 and Power11 processors. Without this flag set, code that checks for Power11 using cpu_has_feature(CPU_FTR_P11_PVR) will incorrectly return false on Power11+ systems using dt-cpu-ftrs, leading to incorrect behavior. This issue manifests specifically in powernv environments (bare-metal or QEMU TCG with powernv machine type), where skiboot/OPAL firmware provides the "ibm,powerpc-cpu-features" node, causing the kernel to use dt-cpu-ftrs. The issue does not affect pseries guests, where SLOF firmware does not provide this node, causing the kernel to fall back to the traditional cputable path (identify_cpu) which correctly sets CPU_FTR_P11_PVR during PVR-based CPU identification. In powernv TCG guests, the missing flag causes KVM code to trigger warnings when attempting to create KVM guests, as cpu_features shows 0x000c00eb8f4fb187 (missing bit 53) instead of the correct 0x002c00eb8f4fb187 (with bit 53 set). Fix this by setting CPU_FTR_P11_PVR for all processors with PVR >= PVR_POWER11 when ISA v3.1 support is detected in cpufeatures_setup_start(). This approach ensures forward compatibility with future processor generations. Fixes: 96e266e3bcd6 ("KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Amit Machhiwal Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260614173437.26352-1-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 8e7709aaed667b62b5e03526bf737f24cdb7ce7f Author: Jinjiang Tu Date: Fri Jun 26 09:32:52 2026 +0800 fs/proc: fix KPF_KSM reported for all anonymous pages commit 81401cebfc1598306b0a981b5f9ee5b58c1aac52 upstream. Reading /proc/kpageflags for any anonymous page returns KPF_KSM set, even when KSM is not in use. As a result, tools misclassify all anonymous pages as KSM merged. In stable_page_flags(), if the page is anonymous, then use (mapping & FOLIO_MAPPING_KSM) check to identify if the anonymous page is KSM page. However, FOLIO_MAPPING_KSM is FOLIO_MAPPING_ANON | FOLIO_MAPPING_ANON_KSM, (mapping & FOLIO_MAPPING_KSM) check returns true for all anonymous pages. To fix it, use FOLIO_MAPPING_ANON_KSM instead. Link: https://lore.kernel.org/20260629033122.774318-1-tujinjiang@huawei.com Link: https://lore.kernel.org/20260626013252.2846774-1-tujinjiang@huawei.com Fixes: dee3d0bef2b0 ("proc: rewrite stable_page_flags()") Signed-off-by: Jinjiang Tu Acked-by: David Hildenbrand (Arm) Acked-by: Zi Yan Reviewed-by: Xu Xin Cc: Chengming Zhou Cc: Kefeng Wang Cc: Luiz Capitulino Cc: Matthew Wilcox (Oracle) Cc: Miaohe Lin Cc: Nanyong Sun Cc: Svetly Todorov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b09d5ad003388e3c3501e05955cf241901c9a846 Author: Krzysztof Wilczyński Date: Sat Jun 13 21:10:05 2026 +0000 proc: only bump parent nlink when registering directories commit 16b02eb4b9b272c221255c20d34ccd5db53a3ed3 upstream. proc_register() increments the parent directory's link count for every entry it registers, while remove_proc_entry() and remove_proc_subtree() decrement it only when the removed entry is a directory. Regular files thus inflate the parent's count while they exist, and leak one link permanently on every create and remove cycle. For example, /proc/bus/pci/00 with twenty-two device files and no subdirectories reports nlink 24 instead of 2, and SR-IOV VF enable and disable cycles, each creating and removing the VF config space entries under /proc/bus/pci/, inflate the link count of that directory without bound. Before commit e06689bf5701 ("proc: change ->nlink under proc_subdir_lock"), the increment lived in proc_mkdir_data() and proc_create_mount_point(), and was therefore applied only to directories. Moving it into proc_register() to bring it under proc_subdir_lock dropped the S_ISDIR check. Thus, move the nlink accounting into pde_subdir_insert() and pde_erase(), only updating it for directories in both, so the link count is always changed together with the directory entry itself. Fixes: e06689bf5701 ("proc: change ->nlink under proc_subdir_lock") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Krzysztof Wilczyński Link: https://patch.msgid.link/20260613211005.921692-1-kwilczynski@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 319caaca072adc564ac9c5357ed013909f23d5ab Author: Dev Jain Date: Thu Jun 4 05:53:05 2026 +0000 fs/proc/task_mmu: do not warn on seeing non-migration pmd entry commit cd1fc0e3c1f67c0c31dfc215e5d9b771133dedc0 upstream. Patch series "mm/hmm: A fix and a selftest", v3. Patch 1 fixes a stale warning present from the time when only migration softleaf entries were supported at the PMD level. Patch 2 adds some code into hmm-tests.c which exercises the pagemap path for PMD device-private entries. This patch (of 2): pagemap_pmd_range_thp() warns if a non-present PMD is not a migration entry. This became false once device-private entries at the PMD level were added. Therefore, remove the stale migration-only assertion. Link: https://lore.kernel.org/20260604055308.1947679-1-dev.jain@arm.com Link: https://lore.kernel.org/20260604055308.1947679-2-dev.jain@arm.com Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Dev Jain Reviewed-by: Balbir Singh Reviewed-by: Lorenzo Stoakes Tested-by: Lorenzo Stoakes Acked-by: David Hildenbrand (Arm) Reviewed-by: Oscar Salvador (SUSE) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5ac8f1c56ba16d94dd22a94480d30a40bb61a04d Author: Kiryl Shutsemau (Meta) Date: Fri May 29 18:23:26 2026 +0100 fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry() commit 1b074e3270e1c061c829150c742eb83bad4dddd1 upstream. The partial-page check compares against HPAGE_SIZE (PMD_SIZE), which is wrong for gigantic hugetlb hstates (e.g. 1G). The walker hands the callback a huge_page_size()-sized range, never start + HPAGE_SIZE, so the comparison always declares it partial and aborts the WP. Compare against the actual hstate's page size. Link: https://lore.kernel.org/20260529172331.356655-3-kas@kernel.org Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Reviewed-by: Lorenzo Stoakes Reviewed-by: Dev Jain Cc: David Hildenbrand Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Balbir Singh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 18b8a9700610299819d21fd0ea85d24726d17f65 Author: Kiryl Shutsemau (Meta) Date: Fri May 29 18:23:27 2026 +0100 fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole() commit e92d92bbafb264dc0518d52b846a3c07ed8d523f upstream. A PAGEMAP_SCAN ioctl requesting PM_SCAN_WP_MATCHING on a hugetlb VMA hangs the calling thread, unkillably, as soon as the scan reaches an unpopulated part of the range: do_pagemap_scan() walk_page_range() walk_hugetlb_range() hugetlb_vma_lock_read() # take the vma lock for read ... pagemap_scan_pte_hole() # ... ->pte_hole() for a hole uffd_wp_range() change_protection() hugetlb_change_protection() hugetlb_vma_lock_write() # ... and block taking it for write walk_hugetlb_range() holds the hugetlb vma lock for read across the whole walk. A present entry goes to ->hugetlb_entry(); an unpopulated one goes to ->pte_hole(), i.e. pagemap_scan_pte_hole(). To write-protect the hole that handler calls uffd_wp_range(), which on a hugetlb VMA reaches hugetlb_change_protection() and takes the same vma lock for write. The thread then blocks in down_write() waiting for the read lock it is itself holding. The populated path avoids this: pagemap_scan_hugetlb_entry() write-protects the entry inline under the page-table lock and never enters hugetlb_change_protection(). Do the same for holes. Fault in the page table and install the uffd-wp marker directly with make_uffd_wp_huge_pte() under the page-table lock, rather than routing through uffd_wp_range(). That is the same sequence hugetlb_change_protection() runs for an unpopulated entry, minus the vma write lock -- which is safe to skip because PMD sharing is disabled on uffd-wp VMAs (hugetlb_unshare_all_pmds() runs at registration), leaving nothing for that lock to serialise against. Link: https://lore.kernel.org/20260529172331.356655-4-kas@kernel.org Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Assisted-by: Claude:claude-opus-4-8 Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Balbir Singh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6b7f774b8882445d9174681747d37c42548686a4 Author: Kiryl Shutsemau (Meta) Date: Fri May 29 18:23:25 2026 +0100 fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race commit 04718f7c9290f95385f0dd328758753dc1c36dec upstream. Patch series "userfaultfd/pagemap: pre-existing fixes". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry Reported-by: Sashiko AI review . They are independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against. Link: https://lore.kernel.org/20260529172331.356655-1-kas@kernel.org Link: https://lore.kernel.org/20260529172331.356655-2-kas@kernel.org Link: https://lore.kernel.org/all/20260526130509.2748441-1-kirill@shutemov.name/ [1] Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Reviewed-by: Lorenzo Stoakes Reviewed-by: Dev Jain Cc: David Hildenbrand Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Balbir Singh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6b6b5d7c2c957136b92c00b77b7175259f13082b Author: SJ Park Date: Wed Jun 17 17:56:48 2026 -0700 mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error commit 05ea83ee88ca70f8932906d9f2617ff996f45b50 upstream. damon_sysfs_scheme_add_dirs() setup the tried_regions directory after the stats directory setup is completed. When the tried_regions directory setup is failed, the setup function ensures the reference for the tried regions directory is released. Hence the error path should put references on setup succeeded directory objects, starting from the stats directory. However, the error path is putting the tried_regions directory instead of the stats directory. As a direct result, the stats directory object is leaked. Worse yet, if the tried_regions directory setup failed from the initial allocation, the scheme->tried_regions field remains uninitialized. The following kobject_put(&scheme->tried_regions->kobj) call in the error path will dereference the uninitialized memory. The setup failures should not be common. But once it happens, the consequence is quite bad. Fix this issue by correctly putting the stats directory instead of the tried_regions directory. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260618005650.83868-3-sj@kernel.org Link: https://lore.kernel.org/20260617005223.96813-1-sj@kernel.org [1] Fixes: 5181b75f438d ("mm/damon/sysfs-schemes: implement schemes/tried_regions directory") Signed-off-by: SeongJae Park Cc: # 6.2.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ee59df7a886a35113f309e3eb791060c46f79bb1 Author: SJ Park Date: Wed Jun 17 17:56:47 2026 -0700 mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs() commit d58fdbe37a829fd2e5803dd4e5a72992dd8c5368 upstream. Patch series "mm/damon/sysfs-schemes: fix wrong directories put orders in error paths". Error paths of damon_sysfs_access_pattern_add_dirs() and damon_sysfs_scheme_add_dirs() functions put references to directories in wrong orders. As a result, uninitialized memory dereference and/or memory leak can happen. Fix those. This patch (of 2): In access_pattern_add_dirs(), error handling path puts references starting from setup failed directories. If the failure happpened from the initial allication in the setup functions, uninitialized memory dereference happen. The allocation failures will not commonly happen, but the consequence is quite bad. Fix the wrong reference put orders. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260618005650.83868-2-sj@kernel.org Link: https://lore.kernel.org/20260617060005.86852-1-sj@kernel.org [1] Fixes: 7e84b1f8212a ("mm/damon/sysfs: support DAMON-based Operation Schemes") Signed-off-by: SeongJae Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 837f619f1d98e967bd63e51ecd1e77bfa468992d Author: SJ Park Date: Thu Jun 4 18:38:48 2026 -0700 mm/damon/core: always put unsuccessfully committed target pids commit 6a66c557a2ab2609575bafd15e093669c05f9711 upstream. damon_commit_target() puts and gets the destination and the source target pids. It puts the destination target pid because it will be overwritten by the source target pid. It gets the source pid because the caller is supposed to eventually put the pids. In more detail, the caller will call damon_destroy_ctx() after damon_commit_ctx() to destroy the entire source context. And in this case, [f]vaddr operation set's cleanup_target() callback will put the pids. The commit operation is made at the context level. The operation can fail in multiple places including in the middle and after the targets commit operations. For any such failures, immediately the error is returned to the damon_commit_ctx() caller. If some or all of the source target pids were committed to the destination during the unsuccessful context commit attempt, those pids should be put twice. The source context will do the put operations using the above explained routine. However, let's suppose the destination context was not originally using [f]vaddr operation set and the commit failed before the ops of the source context is committed. The destination does not have the cleanup_target() ops callback, so it cannot put the pids via the damon_destroy_ctx(). As a result, the pids are leaked. The issue in the real world would be not very common. The commit feature is for changing parameters of running DAMON context while inheriting internal status like the monitoring results. The monitoring results of a physical address range ain't have things that are beneficial to be inherited to a virtual address ranges monitoring. So the problem-causing DAMON control would be not very common in the real world. That said, it is a supported feature. And damon_commit_target() failure due to memory allocation is relatively realistic [1] if there are a huge number of target regions. Fix by putting the pids in the commit operation in case of the failures. The issue was discovered [2] by Sashiko. Link: https://lore.kernel.org/20260605013849.83750-1-sj@kernel.org Link: https://lore.kernel.org/20260603112306.58490-1-akinobu.mita@gmail.com [1] Link: https://lore.kernel.org/20260320020056.835-1-sj@kernel.org [2] Fixes: 83dc7bbaecae ("mm/damon/sysfs: use damon_commit_ctx()") Signed-off-by: SeongJae Park Cc: # 6.11.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 36e4843fe39ea2f17f4de6d59fba26271916c184 Author: Zishun Yi Date: Sat Jun 6 20:17:58 2026 -0600 riscv: cacheinfo: Fix node reference leak in populate_cache_leaves commit bf4a195f063b0a0805c1417f6aad1dd32ea48f0f upstream. Currently, the while loop drops the reference to prev in each iteration. If the loop terminates early due to a break, the final of_node_put(np) correctly drops the reference to the current node. However, if the loop terminates naturally because np == NULL, calling of_node_put(np) is a no-op. This leaves the last valid node stored in prev without its reference dropped, resulting in a node reference leak. Fix this by changing the final `of_node_put(np)` to `of_node_put(prev)`. Fixes: 94f9bf118f1e ("RISC-V: Fix of_node_* refcount") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Zishun Yi Link: https://patch.msgid.link/20260509074040.1747800-1-vulab@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 2611f7521c6c124b1bef1be4fc319e0ca144502f Author: Kiryl Shutsemau (Meta) Date: Fri May 29 18:23:28 2026 +0100 mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade commit f7e2c21bd1f57cd5350eecdfdb5d6025ca6afbab upstream. change_non_present_huge_pmd() rewrites a writable device-private PMD swap entry into a readable one without carrying pmd_swp_uffd_wp() across. The PTE-level change_softleaf_pte() does this correctly; mirror that here, matching what copy_huge_pmd() does for the fork path. Without the carry, a plain mprotect() over a UFFD_WP-marked device-private THP strips the bit and the trap is bypassed on swap-in. Link: https://lore.kernel.org/20260529172331.356655-5-kas@kernel.org Fixes: 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Reviewed-by: Balbir Singh Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a1dd41d00c57efb1fbc6f361c5f48c9d00cca51c Author: Aaron Tomlin Date: Tue May 26 10:16:51 2026 -0400 mips: sched: Fix CPUMASK_OFFSTACK memory corruption commit 98e37db4a34d3af3fb2f4648295c25b5e40b20e3 upstream. This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer. Fixes: 295cbf6d63165 ("[MIPS] Move FPU affinity code into separate file.") Cc: stable@vger.kernel.org Signed-off-by: Aaron Tomlin Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 4d46e07b23d8e2a2e5ac61816a9fc0d9726b5a9d Author: Bryam Vargas Date: Thu Jun 4 23:17:05 2026 +0000 selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path commit 76579d09beedaffe7fe76e9c05644f73983e1ceb upstream. Add regression tests for the LANDLOCK_SCOPE_SIGNAL handling of the asynchronous SIGIO delivery path (fcntl(F_SETOWN)) with a process-group owner. sigio_to_pgid_members covers the bypass: a sandboxed process at the head of its process group's PGID hlist (the default after fork()) arms F_SETOWN(-pgrp) + O_ASYNC and triggers the fan-out; the in-domain owner must be signaled (proving the trigger fired) while the non-sandboxed member of the group, outside the domain, must not. sigio_to_pgid_self covers the same-process guarantee: the owner is registered from a sandboxed non-leader thread, whose domain differs from the thread-group leader the kernel signals for a process-group owner. That leader belongs to the owner's own process and must still be signaled. Without the fix the first test sees the out-of-domain member signaled and the second sees the owner's own leader denied. Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Günther Noack Link: https://patch.msgid.link/43370e89f7a896a583bf33d1cd171d02630e61bf.1780614610.git.hexlabsecurity@proton.me [mic: Fix comment] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit e8631b883338ea4c3b5d8ddfbe16407af9f0b4b9 Author: WenTao Liang Date: Thu Jun 11 08:53:21 2026 +0800 power: supply: charger-manager: fix refcount leak in is_full_charged() commit 4373cfa38ead58f980362c841b0d0bdf8c4d956c upstream. In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference. Cc: stable@vger.kernel.org Fixes: e132fc6bb89b ("power: supply: charger-manager: Make decisions focussed on battery status") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260611005322.53096-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 04916f7dc6d37cd478b06c86398c34a6963ac8c9 Author: Bryam Vargas Date: Thu Jun 4 23:16:56 2026 +0000 landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path commit 4b80320ca7ed03d6e683f95b6066565dc97b9f92 upstream. LANDLOCK_SCOPE_SIGNAL must prevent a sandboxed process from signaling processes outside its Landlock domain. It can be bypassed through the asynchronous SIGIO delivery path. A sandboxed process that owns any file or socket can arm it with fcntl(fd, F_SETOWN, -pgid), fcntl(fd, F_SETSIG, SIGKILL) and O_ASYNC, so that an I/O event makes the kernel deliver the chosen signal to the whole process group. As the head of its process group's task list (the default position right after fork()) that group can also hold the non-sandboxed process that launched it, e.g. a supervisor or a security monitor. The sandbox can thus kill or signal the processes LANDLOCK_SCOPE_SIGNAL is meant to protect from it. The scope is enforced in hook_file_send_sigiotask() against the Landlock domain recorded at F_SETOWN time, not the live domain of the sender. control_current_fowner() decides whether to record that domain and skips recording it when the fowner target is in the caller's thread group, which is safe only for a single-task target (PIDTYPE_PID, PIDTYPE_TGID). For a process group (PIDTYPE_PGID) pid_task() returns only one member; recording is skipped whenever that member shares the caller's thread group, and hook_file_send_sigiotask() then lets the signal fan out to the whole group unchecked. Record the domain for every non single-process target so the scope is enforced against each group member at delivery time. That recording is necessary but not sufficient on its own: the kernel signals a process group through its members' thread-group leaders, and the leader of the registrant's own process can carry a different Landlock domain than the sibling thread that armed the owner. domain_is_scoped() would then deny that leader, even though commit 18eb75f3af40 ("landlock: Always allow signals between threads of the same process") requires same-process delivery to be allowed. hook_task_kill() avoids this by evaluating same_thread_group() live, per recipient; the SIGIO path instead delegates the whole decision to a single registration-time check, which a process-group fan-out cannot honor. So also record the registrant's thread group next to its domain and exempt it at delivery: hook_file_send_sigiotask() allows the signal whenever the recipient belongs to the registrant's own process, restoring the same-process guarantee while keeping out-of-domain group members blocked. The direct kill() path (hook_task_kill) already evaluates the live domain and is unaffected. Fixes: 18eb75f3af40 ("landlock: Always allow signals between threads of the same process") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Günther Noack Link: https://patch.msgid.link/56bffc24f3d0d08b45a686a48e99766b0a0821fa.1780614610.git.hexlabsecurity@proton.me [mic: Check pid_type earlier and improve comment, fix commit message, fix comment formatting] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 7d7f72cb21a829682f6d8968af4fbe413789d1fd Author: Peiyang He Date: Sun Jul 5 19:14:09 2026 +0800 ntfs: fix hole runlist memory leak in insert range error path commit 06769b8f23b4b645b270c438649fff79768fb6fe upstream. ntfs_non_resident_attr_insert_range() allocates hole_rl before mapping the whole runlist. If ntfs_attr_map_whole_runlist() fails, the error path drops ni->runlist.lock and returns without freeing hole_rl. This leaks memory of sizeof(*hole_rl) * 2 bytes. Fix this memory leak by freeing hole_rl before returning from that error path, matching the later error paths in the same function. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit b397b1238a217264bb02f963a1a1eadf71906375 Author: Namjae Jeon Date: Thu Jul 2 10:31:44 2026 +0900 ntfs: fix WARN_ON for resident attribute in ntfs_map_runlist_nolock() commit b8d6c528e9d57d263fee1a648409f84a68b2561d upstream. When ntfs_map_runlist_nolock() needs to look up the attribute extent containing a target VCN (ctx_needs_reset == true), it calls ntfs_attr_lookup() and then expects the result to be a non-resident attribute, since only non-resident attributes have a mapping pairs array to decompress. A crafted NTFS image can place a resident attribute where a non-resident one is expected, causing ntfs_attr_lookup() to succeed but return a resident attribute record. Previously this was caught only by a WARN_ON(), which does not stop execution. The code then falls through to read a->data.non_resident.highest_vcn from what is actually a resident attribute, accessing the wrong union member and corrupting the VCN range check. The caller path triggering this warning during mount is: ntfs_map_runlist_nolock ntfs_empty_logfile load_system_files ntfs_fill_super In this path ctx is NULL, so ntfs_map_runlist_nolock() allocates a temporary search context internally and sets ctx_needs_reset = true. The existing resident-attribute guard in the ctx != NULL branch already returns -EIO silently for the same condition; make the ctx_needs_reset path consistent by replacing the WARN_ON() with the same -EIO error return. This causes the crafted image to be rejected with a mount error instead of triggering a kernel warning. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Reported-by: Sangho Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 8f313e92522ac41d273ea137db13ea8a8df2beed Author: Namjae Jeon Date: Thu Jul 2 20:36:59 2026 +0900 ntfs: make system files immutable to prevent corruption commit f72df3a4c33b64de3418ec74d1ad4f028e09d161 upstream. When a system file such as $Bitmap is exposed via show_sys_files and written from userspace, the volume is corrupted and, because the cluster allocator scans $Bitmap through the same inode's page cache, a write to $Bitmap also deadlocks writeback against the folio it already holds locked. These files are maintained by the driver itself and have no valid reason to be written through the file interface. Mark base metadata files (mft_no < FILE_first_user) as immutable during inode read so the VFS rejects write, mmap, truncate and unlink with -EPERM. Directories are skipped so the root and $Extend remain usable. Internal metadata updates do not go through the VFS write path and are unaffected. Fixes: af0db57d4293 ("ntfs: update inode operations") Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 5a5f877c5df7605e9bae524a25ec0df9b9cb8ea8 Author: Hyunchul Lee Date: Thu Jul 2 14:28:16 2026 +0900 ntfs: avoid self-deadlock during inode eviction commit 77dc384207d5fa63ba97c3bf3285fe1215a1cbf6 upstream. An attribute-list update performed while allocating clusters can drop the last reference to the temporary attribute inode. Evicting that inode drops its reference to the base inode and can invoke ntfs_drop_big_inode() for the base inode from within the base inode's own writeback path. If the base inode is unlinked, ntfs_drop_big_inode() calls truncate_setsize(), which waits for the inode's folio writeback to complete. The same writeback worker is responsible for completing that writeback, so it waits for itself indefinitely. Prevent this self-deadlock by grabbing a reference to the base inode at the beginning of ntfs_writepages() and releasing it at the end of the function. This defers eviction until all bios have been submitted, allowing the wait for folio writeback to complete safely. Fixes: b041ca562526 ("ntfs: update iomap and address space operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 83f396d881c4fd312c7fd5fff2c157fc21104464 Author: Namjae Jeon Date: Mon Jul 6 12:00:00 2026 +0900 ntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name() commit d97a36bae86a9a4021562ded2987f904e6bcb1d7 upstream. ntfs_lookup_inode_by_name() returns MFT references read from directory index entries on disk. These values are untrusted, but the function can currently return an error-marked MFT reference to its callers without validating it. Callers later decode lookup failures with MREF_ERR(). A crafted NTFS image can set the MREF error bit while leaving the low bits as an arbitrary value, causing callers to consume a bogus pseudo-errno instead of treating the lookup result as corrupted on-disk metadata. Fix this at the source by normalizing every error-marked MFT reference returned from ntfs_lookup_inode_by_name() to ERR_MREF(-EIO). Apply this to all four directory lookup return paths so every caller gets a validated result without needing additional checks or an API change. This keeps the sanitization in the common lookup helper, which is cleaner than duplicating validation in each caller. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Cc: stable@vger.kernel.org Reported-by: Hongling Zeng Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d5379035355c0dcb1e92a2544d40f48441e1d637 Author: Peiyang He Date: Mon Jul 6 12:00:15 2026 +0800 ntfs: fail attrlist updates when the superblock is inactive commit 0ebe8f625ab0520217a425d7cd366e4670484941 upstream. generic_shutdown_super() clears SB_ACTIVE before evicting cached inodes. If eviction selects the fake inode for a base inode's unnamed $ATTRIBUTE_LIST attribute, ntfs_evict_big_inode() drops the fake inode's reference on the base inode while the fake inode is still hashed and marked I_FREEING. That iput can synchronously write back the base inode. The writeback path may update mapping pairs and call ntfs_attrlist_update(), which unconditionally calls ntfs_attr_iget() for the same $ATTRIBUTE_LIST fake inode. VFS then finds the I_FREEING inode and waits for eviction to finish, but the current task is still inside that eviction path, causing a self-deadlock in find_inode(). Fix this by mirroring the teardown guard used by __ntfs_write_inode(): once SB_ACTIVE has been cleared, do not try to iget the attribute-list fake inode. Return -EIO so teardown aborts the update instead of waiting on the inode it is evicting. Reported-by: Peiyang He Closes: https://lore.kernel.org/all/AB8D5E603E6EA856+ae5f622a-dd3a-4e38-bdd2-42276ae0e1a8@smail.nju.edu.cn/ Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Assisted-by: Codex:gpt-5.5 Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit b3d09502b80dfe0bab9090ca532710da389f6c7f Author: Peiyang He Date: Tue Jun 30 11:08:56 2026 +0800 ntfs: fix mrec_lock ABBA deadlock in rename commit eb94f5a41a193a425e09a63cb75dffd151d8f42e upstream. ntfs_file_fsync(), ntfs_dir_fsync() and __ntfs_write_inode() lock an inode's mrec_lock before taking the mrec_lock of its parent directory. ntfs_rename() takes old_ni->mrec_lock and old_dir_ni->mrec_lock before taking new_ni->mrec_lock for an existing target, or new_dir_ni->mrec_lock for a cross-directory rename. This can deadlock when ntfs_file_fsync() or __ntfs_write_inode() holds the target inode, or when ntfs_dir_fsync() holds a child target directory, while rename() holds the parent directory and waits for the target. Fix this by locking the existing target inode before taking any parent directory mrec_lock. For cross-directory renames where the target parent is a descendant of the source parent, lock the target parent before the source parent so the directory order matches the child-to-parent order used by ntfs_file_fsync(), ntfs_dir_fsync(), and __ntfs_write_inode(). Reported-by: Peiyang He Closes: https://lore.kernel.org/all/C4D296F0E9F3D66C+9397ffbc-eb55-44bb-9b3f-5da4809e7955@smail.nju.edu.cn/ Fixes: af0db57d4293 ("ntfs: update inode operations") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Assisted-by: Codex:gpt-5.5 Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit a93980141253c932aa6ae5d4422d90e0162dc774 Author: Tristan Madani Date: Sat Apr 18 13:11:18 2026 +0000 ntfs3: fix out-of-bounds read in decompress_lznt commit 7160a57192fb16d7a6fa9b7f5c7ac341d2444a89 upstream. decompress_lznt() does not validate array index bounds before accessing the decompression table. A corrupted NTFS3 image with invalid compressed data can trigger an out-of-bounds read. Add index bounds checking to prevent the OOB access. Reported-by: syzbot+39b2fb0f2638669008ec@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 1758a564b6ebe7f4a82f23c9851d1cae15549457 Author: Michael Bommarito Date: Fri Apr 17 18:57:12 2026 -0400 ntfs3: validate split-point offset in indx_insert_into_buffer commit f1df9d771df47aa40de6d70949c28720ae1e430d upstream. indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e ("fs/ntfs3: Fix OOB read in indx_insert_into_buffer") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Reported-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit d240f5f9d036b8180224954d9873f172b6be4dd8 Author: Michael Bommarito Date: Fri Apr 17 19:33:05 2026 -0400 ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head commit 9b6926ac9c970ae0b2c2fe6289b16e9aa10b6a67 upstream. indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit d313416280d41bea272f02a6034dfa88008692a0 Author: Michael Bommarito Date: Sun May 17 19:41:40 2026 -0400 ntfs3: cap RESTART_TABLE free-chain walker at rt->used commit 9611f644302c07d21bc8af97e3e06a3d30064253 upstream. A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness). Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 36feda687afebae24c472202694448738809c411 Author: Michael Bommarito Date: Tue May 19 05:51:35 2026 -0400 fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} commit 3e127829e57f5190f612412ece4541cb96d5ec7a upstream. In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch "fs/ntfs3: prevent oob in case UpdateRecordDataRoot" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Reported-by: Pavitra Jha Closes: https://lore.kernel.org/ntfs3/20260502105008.21827-1-jhapavitra98@gmail.com/ Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit fdf50c788e0991e42a187ff75479a0df7fb752f1 Author: Michael Bommarito Date: Mon Apr 13 09:31:17 2026 -0400 fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow commit 1ebd684b8f627f75bc3e03f8b2ad8400fd1f02cd upstream. indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 32b9f8733feb241627fa5f564b1a99b5cae974c5 Author: Konstantin Komarov Date: Mon Jun 1 10:57:56 2026 +0200 fs/ntfs3: validate lcns_follow in log_replay conversion commit 6a4c53a2e26a865565bd6a460961e8d6fcb32329 upstream. log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: memmove(&dp->vcn, &dp0->vcn_low, 2 * sizeof(u64) + le32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha [almaz.alexandrovich@paragon-software.com: fixed the conflicts] Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit a89c66674283a0293c0f266dc57087a6114371a3 Author: Konstantin Komarov Date: Tue Jun 2 15:15:47 2026 +0200 fs/ntfs3: bound attr_off in UpdateResidentValue against data_off commit d1570c48f49a693974d000251030370ee2e83539 upstream. In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment attr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito [almaz.alexandrovich@paragon-software.com: clang-formatted the changes] Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 49c86dae0c0ccb8d98ddcdc46987259389c816dd Author: Michael Bommarito Date: Fri May 15 12:34:05 2026 -0400 fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass commit 5e7b598660cfa8e5af172cf4c65cffc126333307 upstream. In log_replay()'s analysis pass, after find_dp() returns a valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple, the copy_lcns block walks lrh->lcns_follow further entries: t16 = le16_to_cpu(lrh->lcns_follow); for (i = 0; i < t16; i++) { size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) - le64_to_cpu(dp->vcn)); dp->page_lcns[j + i] = lrh->page_lcns[i]; } find_dp() only validates that target_vcn falls within [dp->vcn, dp->vcn + dp->lcns_follow), i.e., that the FIRST cluster is covered. The walk through the further entries is not bounded against dp->lcns_follow. For a malformed LRH where target_vcn = dp->vcn + dp->lcns_follow - 1 and lrh->lcns_follow > 1, the i > 0 writes overflow the dp's allocated page_lcns[] array. Add the missing j + lrh->lcns_follow <= dp->lcns_follow guard. Reproduced under UML+KASAN on mainline 8d90b09e6741 as a slab-out-of-bounds write of size 8 from log_replay+0x68d4 on the mount path. This is distinct from Pavitra Jha's 2026-05-02 patch ("fs/ntfs3: validate lcns_follow in log_replay conversion", <20260502154252.164586-1-jhapavitra98@gmail.com>) which addresses the separate version-0 dirty-page-table conversion path's memmove(&dp->vcn, ...) call. The two fixes are complementary; both should land. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito [almaz.alexandrovich@paragon-software.com: clang-formatted the changes, fixed conflicts] Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 554700c65d398276cb00a8ef95f1d5e00b9eff93 Author: Konstantin Komarov Date: Tue Jun 2 15:21:03 2026 +0200 fs/ntfs3: bound DeleteIndexEntryAllocation memmove length commit fc4626bb3656362de8b0ecd56605d47a19ec3518 upstream. In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: if (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || used + esize > le32_to_cpu(hdr->total)) { goto dirty_vol; } Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito [almaz.alexandrovich@paragon-software.com: clang-formatted the changes] Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 0079773250213bb1ad2a49ee0b0a8eeaba9f1e2b Author: Zhan Xusheng Date: Wed May 6 15:55:54 2026 +0800 fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename commit 932fa0c1496286e39e14e27194c1ee7c2181629f upstream. In ntfs3_rename(), when IS_DIRSYNC(new_dir) is true, the code syncs the renamed file inode instead of the target directory new_dir: if (IS_DIRSYNC(new_dir)) ntfs_sync_inode(inode); /* should be new_dir */ DIRSYNC requires that directory metadata changes are written to disk synchronously. Since new_dir was modified (a new directory entry was added), it is new_dir that must be synced to satisfy the guarantee, not the renamed file itself. This bug has existed since the initial ntfs3 implementation and was carried through the refactoring in commit 78ab59fee07f ("fs/ntfs3: Rework file operations"). Fix by syncing new_dir instead of inode. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit b54c9beb90e570bae17a9c18442aeeaf17165ccb Author: DaeMyung Kang Date: Tue Jun 9 00:49:14 2026 +0900 ntfs: reject non-resident records for resident-only attributes commit 097cdfd0a55df5af82c9753833f39a8bfadbcfcb upstream. The shared lookup-time attribute validator rejects non-resident $FILE_NAME and $VOLUME_NAME records because their formats require resident values and callers handle returned records as resident attributes. Other resident-only attribute types still pass through the generic non-resident mapping-pairs checks. That leaves real resident/non-resident union confusion paths. Inode load looks up $STANDARD_INFORMATION and then reads data.resident.value_offset without checking a->non_resident. ntfs_inode_sync_standard_information() does the same when updating the standard information value. ntfs_write_volume_flags() also looks up $VOLUME_INFORMATION and reads data.resident.value_offset directly. $INDEX_ROOT callers in dir.c and index.c depend on the same lookup contract before consuming the resident index root value. Reject non-resident records for all resident-only attribute types in the shared validator. Keep the existing $FILE_NAME and $VOLUME_NAME behavior, but factor it through a helper and extend it to $STANDARD_INFORMATION, $OBJECT_ID, $VOLUME_INFORMATION, $INDEX_ROOT, and $EA_INFORMATION. For $OBJECT_ID and $EA_INFORMATION this is contract hardening for resident-only formats; this patch only rejects the non-resident form and does not add new resident value validation for those types. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit bfb01dd319b6b4c3e79756de7b75ccf0b9a0a247 Author: DaeMyung Kang Date: Tue Jun 9 00:49:17 2026 +0900 ntfs: validate resident index root values on lookup commit fcf5bf0e8570798970e3ae8c95d04765ba2c5b97 upstream. Resident $INDEX_ROOT values carry index header fields that callers consume after lookup. Some callers already validate parts of the layout before walking entries, but those checks are scattered and do not cover all root header invariants, such as entries_offset alignment and lower bound, index_length, and allocated_size consistency. The resident root resize paths now keep these header fields consistent while the value size changes: ntfs_ir_truncate() lowers index.allocated_size before shrinking the resident value, and ntfs_ir_reparent() grows the resident value before publishing a larger root header. Lookup-time validation can therefore cover these invariants without tripping over the driver's own resize paths. Add $INDEX_ROOT to the minimum resident value size table and validate the resident index header fields before returning the attribute from lookup. Require 8-byte aligned index header fields, a sane entries_offset, an index_length within allocated_size, allocated_size within the resident value, and enough entry space for at least an index entry header. The shared validator already rejects non-resident records for resident-only attribute types, including $INDEX_ROOT. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 18fe978d265bf971757d3631eae3ea3d68b7b528 Author: DaeMyung Kang Date: Sat May 30 23:35:12 2026 +0900 ntfs: validate resident volume name values on lookup commit b3f6cd1d54aa279cc4f47aa27939ebe517a2c390 upstream. The shared lookup-time attribute validator now has a safe caller path for $VOLUME_NAME corruption: ntfs_write_volume_label() no longer treats lookup errors as an absent label, and the mount path reinitializes its search context before continuing to $VOLUME_INFORMATION. Add $VOLUME_NAME-specific resident value validation. A volume name is stored as a UTF-16LE string, so reject odd byte lengths, and reject values longer than the NTFS volume label limit. Empty labels remain valid. Also reject non-resident $VOLUME_NAME records. $VOLUME_NAME is required to be resident, like $FILE_NAME; a crafted non-resident record would otherwise pass lookup and ntfs_write_volume_label() would remove it as if it were a normal resident attribute. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 82510cb5c658b5bb424dbde9ad96b7a8b1bb332f Author: DaeMyung Kang Date: Sat May 30 23:35:10 2026 +0900 ntfs: do not replace volume name after lookup errors commit 40d88020d0797f96a93edd2e8edc413c2e2d8f84 upstream. ntfs_write_volume_label() removes an existing $VOLUME_NAME attribute and then adds the replacement. The old code only distinguished lookup success from all other results, so any lookup error was treated like an absent label and the add path still ran. That is unsafe once lookup-time validation rejects corrupt $VOLUME_NAME records with -EIO: the corrupt record would remain in place and a second $VOLUME_NAME record could be appended next to it. Only add the replacement after the old label was removed successfully or after lookup returned -ENOENT. Propagate all other lookup errors, and also stop if removing the old attribute fails. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 7fb64788812d137b37f6d8724e1e41c624c1e814 Author: Samuel Moelius Date: Wed Jun 3 17:41:09 2026 +0000 ntfs: detect mapping-pairs LCN accumulator overflow commit ec4f061f2219e0f0c6465d56d0380bf749235a53 upstream. The NTFS mapping-pairs parser accumulates relative LCN deltas in a signed integer. A corrupted attribute can drive that addition past the representable range. One corrupt runlist shape sets the accumulated LCN to S64_MAX and then adds a delta of 1 in the next mapping-pairs entry. Signed overflow is undefined and can turn an invalid runlist into a different set of physical clusters. Check the LCN addition for overflow before storing the next run. Cc: stable@vger.kernel.org # v7.1 Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit e2b95d3adb558ddd5685f9e072ec8661d57ee3a9 Author: Hyunchul Lee Date: Sat May 23 13:14:22 2026 +0900 ntfs: validate index entries on reading commit 2221b691d7b2e17f08153f95848dacaa5d87e21d upstream. Validate index entries immediately after reading an index root or index block from disk. This eliminates repeated checks in lookup and readdir, and reduce the risk of missing checks in those paths. Cc: stable@vger.kernel.org # v7.1 Tested-by: woot000 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 40ee64e633e5e413f2255bb48c063977d8c86f34 Author: DaeMyung Kang Date: Fri May 22 23:20:48 2026 +0900 ntfs: avoid heap allocation for free-cluster readahead state commit c05132077df57a384919f61d7f8a8e76d748a6d4 upstream. get_nr_free_clusters() allocates a temporary file_ra_state before it publishes the precomputed free cluster count, sets NVolFreeClusterKnown(), and wakes vol->free_waitq. If that allocation fails, the worker returns without setting the flag or waking waiters, so callers waiting for the free count can block indefinitely. The readahead state is only used synchronously while scanning the bitmap. Keep it on the stack and pass it by address to the readahead helper. This eliminates the early allocation failure path instead of adding a special case that publishes a conservative count and wakes the waitqueue. Zero-initialize the on-stack state because file_ra_state_init() only sets ra_pages and prev_pos. Apply the same treatment to __get_nr_free_mft_records(), which scans the MFT bitmap with the same short-lived readahead state. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit a9cafa8c780f3b9bec3493db4de418e7d6dda2d8 Author: DaeMyung Kang Date: Thu May 21 19:17:51 2026 +0900 ntfs: only alias volume $UpCase to default on exact match commit 8f4b6e8bda121ae3d4d8e332b789664604d3e9d2 upstream. load_and_init_upcase() currently aliases vol->upcase to the global default upcase whenever the shared prefix matches, and then truncates vol->upcase_len to that shorter prefix. The result is correct only by accident: upcase[] accesses in name collation are gated by upcase_len, so the prefix-equality alias produces the same fold output as keeping the volume's own shorter table. Still, prefix equality is not equality: the volume table is logically distinct from the default and should not be replaced by it unless they are byte-for-byte identical. Use memcmp() to compare the complete table in one expression and drop the now-redundant upcase_len rewrite. No user-visible change is expected for compliant volumes whose $UpCase has exactly default_upcase_len entries; shorter volume tables are no longer aliased to the default. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d7773b7af1d29d668c67e492575d13ae319c1b20 Author: DaeMyung Kang Date: Sat May 30 23:35:11 2026 +0900 ntfs: reinit search context before volume information lookup commit 45dd046ced0f5982a6d64ca449de3a61f5f15669 upstream. On mount the volume inode is searched for $VOLUME_NAME and then, reusing the same search context, for $VOLUME_INFORMATION. The $VOLUME_NAME lookup is optional and its result is otherwise ignored. Once lookup-time validation can reject a corrupt $VOLUME_NAME with -EIO, the search context is left in an undefined state: ntfs_attr_find() documents that on an actual error @ctx->attr is undefined. Continuing the $VOLUME_INFORMATION search from that context is not contractually valid. Reinitialize the search context before the $VOLUME_INFORMATION lookup so it always starts from a well-defined state regardless of the $VOLUME_NAME lookup outcome. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit f831ab09d521898bf1dd99bf5adfd630ea1428e3 Author: Hyunchul Lee Date: Thu May 21 14:37:03 2026 +0900 ntfs: skip extent mft records in writeback to prevent deadlock commit 76bc14c7097ff678b2b5dbfd4fa33b46897d87ce upstream. This patch fixes the ABBA deadlock between extent_lock and extent mrec_lock triggered by xfstests generic/113, that occurs since the commit 6994acf33bae ("ntfs: use base mft_no when looking up base inode for extent record"). Path A (inode writeback): VFS writeback -> ntfs_write_inode() -> __ntfs_write_inode() -> mutex_lock(&ni->extent_lock) -> mutex_lock(&tni->mrec_lock) Path B (MFT folio writeback): VFS writeback of $MFT dirty folios -> ntfs_mft_writepages() -> ntfs_write_mft_block() -> ntfs_may_write_mft_record() -> holds one extent mrec_lock from a previous iteration -> tries to acquire another base inode extent_lock By removing all extent_lock and extent mrec_lock acquisition from the MFT folio writeback path, the ABBA lock ordering is eliminated: Path A: __ntfs_write_inode(): extent_lock -> mrec_lock Path B (removed): ntfs_write_mft_block(): mrec_lock -> extent_lock Path B is always redundant for extent records because: 1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio. It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A. Therefore, normal extent modifications never create a situation where the MFT folio is dirty and Path B is not scheduled. 2. The MFT folio only gets dirtied via ntfs_mft_mark_dirty() inside ntfs_mft_record_alloc(). But all identified callers in attrib.c (ntfs_attr_add, ntfs_attr_record_move_away, ntfs_attr_make_non_resident, ntfs_attr_record_resize) follow through with mark_mft_record_dirty(), which triggers Path A to write the complete record. 3. ntfs_evict_big_inode() calls ntfs_commit_inode() before freeing extent inodes, ensuring all dirty extents are flushed via Path A before the base inode leaves the icache. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit b06730c6af58d3569883f8dd7c36a90aba5ecc0a Author: Hyunchul Lee Date: Sat May 23 13:14:21 2026 +0900 ntfs: centalize $INDEX_ROOT header validation commit 8b97b302f553a480fb76d2afd53cd6c0635a9dcd upstream. Add a dedicated helper to perform stricter validation of $INDEX_ROOT and use it for both directory inodes and named index inodes. This keeps the root size and header geometry checks consistent across both read paths. Cc: stable@vger.kernel.org # v7.1 Tested-by: woot000 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 0527a81e85eeb71a34e15aff305f52cf345d5898 Author: DaeMyung Kang Date: Tue Jun 9 00:49:16 2026 +0900 ntfs: update index root allocated size before shrink commit e782ca90ceb798bb1811b214bf814216f11aae6a upstream. ntfs_ir_truncate() currently shrinks the resident $INDEX_ROOT value first and only updates index.allocated_size after re-looking up the attribute. During that relookup, the resident value_length can already be smaller while index.allocated_size still contains the old larger size. That leaves a transiently inconsistent $INDEX_ROOT layout and prevents lookup-time $INDEX_ROOT validation from being enabled: validation can correctly reject allocated_size extending past the newly shrunk resident value. When shrinking, lower index.allocated_size before shrinking value_length. If the truncate fails, restore the old allocated_size. Keep the existing grow ordering because the old allocated_size remains within the enlarged resident value until it is updated after the relookup. The shrink path is safe because the new value_length still covers struct index_root, so the index.allocated_size field remains present while it is updated first. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit aca3d383a23cb7f3a2849c09fda3974f1838d941 Author: DaeMyung Kang Date: Thu May 21 19:17:49 2026 +0900 ntfs: free volume-wide resources on fill_super failure commit a9523a7d3b24b3a6b25ec1eb668ee6618cacf05e upstream. ntfs_fill_super()'s err_out_now path frees only the volume struct via kfree(vol), leaving several vol-owned allocations behind on every mount failure: - vol->nls_map, loaded by ntfs_init_fs_context() via load_nls_default() (or replaced by an explicit nls= option in ntfs_parse_param()), is never unload_nls()'d. - vol->volume_label, allocated by load_system_files() through ntfs_ucstonls() once the $Volume name attribute has been parsed, is not released by load_system_files()'s own error labels nor by the fill_super() inline cleanup that only runs on d_make_root() failure. Any later failure inside load_system_files() leaks it. - vol->lcn_empty_bits_per_page was kvfree()'d in unl_upcase_iput_tmp_ino_err_out_now without clearing the pointer, so it could not be folded into a single common cleanup. Because the failure paths never call ntfs_volume_free() and never reach the d_make_root() inline cleanup block (it sits above the label and is jumped over by the load_system_files() / kvmalloc failure gotos), these resources accumulate per failed mount attempt with no chance of recovery short of unloading the module. This is a silent leak: the inodes loaded prior to failure remain hashed but generic_shutdown_super() skips evict_inodes() when sb->s_root is unset, so no CHECK_DATA_CORRUPTION warning is emitted either. Move the per-volume frees down to err_out_now and drop the lcn_empty_bits_per_page kvfree() from the upper label so the cleanup is performed exactly once on every failure path. Using unconditional kvfree() / kfree() / unload_nls() is safe because they all accept NULL and the upper labels that previously freed nls_map (the d_make_root() inline cleanup) already clear the pointer. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 34a49b3e94a50f45b62c6e6f574f676a079ba23e Author: Hyunchul Lee Date: Sat May 23 13:14:20 2026 +0900 ntfs: validate index block header more strictly commit 14bc34fe948523dc2b0174691f9af9e74eb4f3fd upstream. Modify ntfs_index_block_inconsisent() to perform stricter validation of INDEX_HEADER geometry in INDX blocks, and update ntfs_lookup_inode_by_name() to use that function to validate INDX blocks. Cc: stable@vger.kernel.org # v7.1 Tested-by: woot000 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit ceb49c37250125d418410988f2376ed4d57a6706 Author: Hyunchul Lee Date: Thu May 28 11:15:35 2026 +0900 ntfs: not change 0-byte $DATA attribute to non-resident commit 0aad21570197973af4a1b25b3fb8ed3aeb9e7670 upstream. When ntfs_resident_attr_resize() cannot grow a resident attribute in place, it retries after converting other resident attributes to non-resident to free space in the MFT recrord. Do not select zero-length resident $DATA attributes for this conversion. fsck treats 0-byte non-resident $DATA attribute as corruptions. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d9d9925de1d8f233cc60d3dc356e12f232f97c15 Author: Hyunchul Lee Date: Sat May 23 13:14:23 2026 +0900 ntfs: add bounds check before accessing EA entries commit 937282f7d15b593d0be765fa2ced164130ec87f7 upstream. in ntfs_ea_lookup and ntfs_listxattr, this verifies that there is enough space in the EA entry before accessing the next_entry_offset field of the EA entry. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit e4c36dfac57a7261e9aeb0f3a7f30944a8aefb56 Author: DaeMyung Kang Date: Sat May 30 23:35:09 2026 +0900 ntfs: validate attribute values on lookup commit d5803e3345dae9c6470bb61869885236276b9a35 upstream. ntfs_attr_find() and ntfs_external_attr_find() check that generic resident attribute values fit in their attribute records and that fixed-size resident values are large enough. For variable-length resident formats, however, the fixed part is not enough: embedded length fields can still point callers past the resident value. A crafted image can set a small resident $FILE_NAME value_length while leaving file_name_length large. Callers then trust file_name_length and read past the resident value when converting or comparing the name. This was reproduced with a crafted image under KASAN as a slab-out-of-bounds read from the kmalloc-1k MFT record copy. The stack included ntfs_lookup(), ntfs_iget(), ntfs_read_locked_inode(), ntfs_attr_name_get(), ntfs_ucstonls(), and utf16s_to_utf8s(). Add a shared attribute value validator and use it before a lookup path can return an attribute, including the AT_UNUSED enumeration case where callers inspect returned attributes directly. The helper validates resident value bounds, minimum resident value sizes, variable-length $FILE_NAME fields, and non-resident mapping-pairs metadata that was previously checked separately in both lookup paths. This also preserves the intended resident @val matching semantics in the external attribute lookup path. The old duplicated validation block overwrote the actual resident value length with the type-specific minimum length before comparing @val, so variable-length resident values could fail to match even when the bytes were identical. Keep the comparison on the actual value length, and make ntfs_attrlist_entry_add() compare resident attributes with lowest_vcn zero instead of reading the non-resident union member after a successful resident match. Reject non-resident $FILE_NAME records too: the format requires $FILE_NAME to be resident and callers treat returned records as resident. Cc: stable@vger.kernel.org # v7.1 Fixes: 6ceb4cc81ef3 ("ntfs: add bound checking to ntfs_attr_find") Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 353a79fb76bf2befd42f7d54e08b9d2aa3d7b25e Author: Marco Crivellari Date: Thu May 14 15:54:08 2026 +0200 ntfs: Add WQ_PERCPU to alloc_workqueue users commit 38e8db370843b518ff9bee4af46c6b800684cc78 upstream. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. For more details see the Link tag below. In order to keep alloc_workqueue() behavior identical, explicitly request WQ_PERCPU. Cc: stable@vger.kernel.org # v7.1 Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit bfe835e535fe0aa5767fdd8116f62e835ba50b55 Author: Ron de Bruijn Date: Sat May 30 09:19:18 2026 +0900 ntfs: fix off-by-one in mapping pairs decoding bounds checks commit 18760a74ef7c28df93726445b5595162e62ed341 upstream. In ntfs_mapping_pairs_decompress(), attr_end points one byte past the end of the attribute record: attr_end = (u8 *)attr + le32_to_cpu(attr->length); The two bounds checks validating that mapping pair data bytes fit within the attribute use strict greater-than (>), which allows a one-byte out-of-bounds read when the data extends exactly to attr_end: b = *buf & 0xf; if (b) { if (unlikely(buf + b > attr_end)) // off-by-one goto io_error; for (deltaxcn = (s8)buf[b--]; b; b--) deltaxcn = (deltaxcn << 8) + buf[b]; } When buf + b == attr_end, the check evaluates to false and buf[b] reads one byte past the valid attribute boundary. The same pattern appears in the LCN delta bytes check. Fix both checks to use >= so that buf[b] at exactly attr_end is correctly rejected as out of bounds. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Ron de Bruijn Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 7d702aee1589e23f72b5914da36f5f74fb7dffb4 Author: Hyunchul Lee Date: Mon Jun 15 08:49:52 2026 +0900 ntfs: fix incorrect size of symbolic link commit 05a5ff86a7f12c861e3516d3dc4d092ce620742d upstream. This patch fixes the issue where a symbolic link size is displayed as 0. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 38d444271604afc6381ddb5a181e391915c35fae Author: DaeMyung Kang Date: Tue Jun 9 00:49:15 2026 +0900 ntfs: grow index root value before reparent header update commit 0bb508fb3b97e4802ec727fd2af4d608f65dd190 upstream. ntfs_ir_reparent() moves the resident index root entries into an index block and leaves a small root stub containing the child VCN. That root stub can be larger than the existing resident value. For example, an empty root with value_length 48 has an index area of 32 bytes, while the large-index root stub needs index_length and allocated_size of 40 bytes. The current code publishes the larger index.index_length and index.allocated_size before resizing the resident value. If the resize returns -ENOSPC, the recovery path can call ntfs_inode_add_attrlist(), which looks attributes up again while the root header says allocated_size 40 but the resident value still only provides 32 bytes of index area. Lookup-time $INDEX_ROOT validation then correctly rejects that transient layout as corrupt. This reproduces as a generic/013 failure under qemu. In the failing run, the transient root had value_len=48, index_size=32, index_length=40, and allocated_size=40, and ntfsprogs-plus ntfsck reported "Corrupt index root in MFT record 1177". When the root stub grows, resize the resident value before publishing the larger root header. If the resize fails, the old root remains valid for recovery lookups. Keep the existing header-before-resize ordering for shrink or same-size cases so the resident value never temporarily exposes an allocated_size beyond its bounds. Cc: stable@vger.kernel.org # v7.1 Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 57094929cf094e563f0fc2f083b192c28767ef78 Author: SJ Park Date: Mon Apr 27 21:29:40 2026 -0700 mm/damon/core: make charge_addr_from aware of end-address exclusivity commit 5a2d162e22bf33eb89d53e802d0fc1ec422e19b6 upstream. DAMON region end address is exclusive one, but charge_addr_from is assigned assuming the end address is inclusive. As a result, DAMOS action to next up to min_region_sz memory can be skipped. This is quite negligible user impact. But, the bug is a bug that can be very simply fixed. Fix the wrong assignment to respect the exclusiveness of the address. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260428042942.118230-1-sj@kernel.org Link: https://lore.kernel.org/20260428032324.115663-1-sj@kernel.org [1] Fixes: 50585192bc2e ("mm/damon/schemes: skip already charged targets and regions") Signed-off-by: SeongJae Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2f9e3ec17c3d2093c664c00a027588a446c39894 Author: Muchun Song Date: Tue Apr 28 16:18:51 2026 +0800 mm/memory_hotplug: fix incorrect altmap passing in error path commit 2fac4afa0e2e68841334c78c1821e49f74fbc66a upstream. In create_altmaps_and_memory_blocks(), when arch_add_memory() succeeds with memmap_on_memory enabled, the vmemmap pages are allocated from params.altmap. If create_memory_block_devices() subsequently fails, the error path calls arch_remove_memory() with a NULL altmap instead of params.altmap. This is a bug that could lead to memory corruption. Since altmap is NULL, vmemmap_free() falls back to freeing the vmemmap pages into the system buddy allocator via free_pages() instead of the altmap. arch_remove_memory() then immediately destroys the physical linear mapping for this memory. This injects unowned pages into the buddy allocator, causing machine checks or memory corruption if the system later attempts to allocate and use those freed pages. Fix this by passing params.altmap to arch_remove_memory() in the error path. Link: https://lore.kernel.org/20260428081855.1249045-3-songmuchun@bytedance.com Fixes: 6b8f0798b85a ("mm/memory_hotplug: split memmap_on_memory requests across memblocks") Signed-off-by: Muchun Song Acked-by: David Hildenbrand (Arm) Acked-by: Liam R. Howlett Reviewed-by: Georgi Djakov Cc: "Aneesh Kumar K.V" Cc: Joao Martins Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Michal Hocko Cc: Mike Rapoport (Microsoft) Cc: Nicholas Piggin Cc: Oscar Salvador Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b785f2bd9496facedc0a031be09cddcd1d3c84d3 Author: Deepanshu Kartikey Date: Sat Mar 28 12:25:34 2026 +0530 mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch commit 15807d0ddde37407af72859426b654f3d1972b00 upstream. In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths. Link: https://lore.kernel.org/20260328065534.346053-1-kartikey406@gmail.com Fixes: 08cf9faf7558 ("hugetlb_cgroup: support noreserve mappings") Reported-by: syzbot+226c1f947186f8fef796@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=226c1f947186f8fef796 Signed-off-by: Deepanshu Kartikey Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Mina Almasry Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fc3f0eef426f1cdea387ce886c86e119f6a898e7 Author: Johan Hovold Date: Tue Apr 7 14:33:38 2026 +0200 power: supply: max17042: fix OF node reference imbalance commit 68d234144b7dffd1f50b07ba74d0d6e833ef43a4 upstream. The driver reuses the OF node of the parent multi-function device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the MFD and deregistering the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 0cd4f1f77ad4 ("power: supply: max17042: add platform driver variant") Cc: stable@vger.kernel.org # 6.14 Cc: Dzmitry Sankouski Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260407123338.2677375-1-johan@kernel.org Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit b56a5cbf8f1f1a5740f1137c89b14d0373309d8d Author: Ma Ke Date: Fri Apr 24 09:10:13 2026 +0800 power: supply: cpcap-battery: Fix missing nvmem_device_put() causing reference leak commit a2c14ff63e0e02e3c832385e523e9cc81301171c upstream. In cpcap_battery_detect_battery_type(), the reference to an nvmem device obtained via nvmem_device_find() is not released with nvmem_device_put() on the success or read-failure paths, causing a permanent reference leak. The driver’s retry logic on subsequent battery property reads can compound this leak, preventing the nvmem device from ever being freed. Found by code review. Signed-off-by: Ma Ke Cc: stable@vger.kernel.org Fixes: fd46821e85de ("power: supply: cpcap-battery: Add battery type auto detection for mapphone devices") Link: https://patch.msgid.link/20260424011013.879639-1-make24@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit b03e62112c9d1acb8120df9679b77fcc4ee7891a Author: Muchun Song Date: Tue Apr 28 16:18:54 2026 +0800 mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages commit 94405c6136839f7c462249c8b4b957bcb9527a9d upstream. The memmap_init_zone_device() function only initializes the migratetype of the first pageblock of a compound page. If the compound page size exceeds pageblock_nr_pages (e.g., 1GB hugepages with 2MB pageblocks), subsequent pageblocks in the compound page remain uninitialized. Move the migratetype initialization out of __init_zone_device_page() and into a separate pageblock_migratetype_init_range() function. This iterates over the entire PFN range of the memory, ensuring that all pageblocks are correctly initialized. Also remove the stale confusing comment about MEMINIT_HOTPLUG above the migratetype setting since it is an obsolete relic from commit 966cf44f637e ("mm: defer ZONE_DEVICE page initialization to the point where we init pgmap") and no longer makes sense here. Link: https://lore.kernel.org/20260428081855.1249045-6-songmuchun@bytedance.com Fixes: c4386bd8ee3a ("mm/memremap: add ZONE_DEVICE support for compound pages") Signed-off-by: Muchun Song Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Oscar Salvador Acked-by: David Hildenbrand (Arm) Acked-by: Liam R. Howlett Cc: "Aneesh Kumar K.V" Cc: Joao Martins Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Michal Hocko Cc: Nicholas Piggin Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3ae86630b94f72bf4012c6322f81f622dc4fdf24 Author: Maciej W. Rozycki Date: Wed May 6 23:42:23 2026 +0100 MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() commit 5ff79e8bdc75db51e30298a75939e2308e7658e0 upstream. In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and "if it ain't broke, don't fix it," so just leave them alone. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 35521e4ec762a8f357ff4bbad5f344b92c135755 Author: Johan Hovold Date: Fri Apr 24 12:28:47 2026 +0200 MIPS: ip22-gio: fix device reference leak in probe commit b82930a4c5dbc5c4df39c0f93d968c239f2c6885 upstream. The gio probe function needlessly takes a device reference which is never released and therefore prevents unbound gio devices from being freed. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Cc: stable@vger.kernel.org # 3.3 Cc: Thomas Bogendoerfer Signed-off-by: Johan Hovold Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit b04bbb89ca3a459330920d90dcda7676511e6911 Author: Johan Hovold Date: Fri Apr 24 12:28:45 2026 +0200 MIPS: ip22-gio: fix kfree() of static object commit c62cdd3e919bdf84c37ec46810f87cdb1736e822 upstream. The gio bus root device is a statically allocated object which must not be freed by kfree() on failure to register the device or bus. Fixes: 82242d28ff8b ("MIPS: IP22: Add missing put_device call") Cc: stable@vger.kernel.org # 3.17 Cc: Levente Kurusa Signed-off-by: Johan Hovold Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit a018c9b8805c53bd92a69e42ca8ea24d61e2f164 Author: Johan Hovold Date: Fri Apr 24 12:28:46 2026 +0200 MIPS: ip22-gio: fix gio device memory leak commit 7de9a1b45f5a95b58145653c525c8fb80292d9ab upstream. The gio device release callback was never wired up so gio devices are not freed when the last reference is dropped. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Cc: stable@vger.kernel.org # 3.3 Cc: Thomas Bogendoerfer Signed-off-by: Johan Hovold Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 25bec992181dfc1eba5d8784e8ab17bef8a41f5d Author: Muchun Song Date: Tue Apr 28 16:18:50 2026 +0800 mm/sparse-vmemmap: fix vmemmap accounting underflow commit c373f7f98e6ad591c85d40548cf8b6443be69311 upstream. Patch series "mm: Fix vmemmap optimization accounting and initialization", v8. The series fixes several bugs in vmemmap optimization, mainly around incorrect page accounting and memmap initialization in DAX and memory hotplug paths. It also fixes pageblock migratetype initialization and struct page initialization for ZONE_DEVICE compound pages. Patches 1-4 fix vmemmap accounting issues. Patch 1 fixes an accounting underflow in the section activation failure path by moving vmemmap page accounting into the lower-level allocation and freeing helpers. Patch 2 fixes incorrect altmap passing in the memory hotplug error path. Patch 3 passes pgmap through memory deactivation paths so the teardown side can determine whether vmemmap optimization was in effect. Patch 4 uses that information to account the optimized DAX vmemmap size correctly. Patches 5-6 fix initialization issues in mm/mm_init. One makes sure all pageblocks in ZONE_DEVICE compound pages get their migratetype initialized. The other fixes a case where DAX memory hotplug reuses an unoptimized early-section memmap while compound_nr_pages() still assumes vmemmap optimization, leaving tail struct pages uninitialized. This patch (of 6): In section_activate(), if populate_section_memmap() fails, the error handling path calls section_deactivate() to roll back the state. This causes a vmemmap accounting imbalance. Since commit c3576889d87b ("mm: fix accounting of memmap pages"), memmap pages are accounted for only after populate_section_memmap() succeeds. However, the failure path unconditionally calls section_deactivate(), which decreases the vmemmap count. Consequently, a failure in populate_section_memmap() leads to an accounting underflow, incorrectly reducing the system's tracked vmemmap usage. Fix this more thoroughly by moving all accounting calls into the lower level functions that actually perform the vmemmap allocation and freeing: - populate_section_memmap() accounts for newly allocated vmemmap pages - depopulate_section_memmap() unaccounts when vmemmap is freed This ensures proper accounting in all code paths, including error handling and early section cases. Link: https://lore.kernel.org/20260428081855.1249045-1-songmuchun@bytedance.com Link: https://lore.kernel.org/20260428081855.1249045-2-songmuchun@bytedance.com Fixes: c3576889d87b ("mm: fix accounting of memmap pages") Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: Oscar Salvador Acked-by: David Hildenbrand (Arm) Acked-by: Liam R. Howlett Cc: "Aneesh Kumar K.V" Cc: Joao Martins Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Michal Hocko Cc: Nicholas Piggin Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f80fafe24f7221bfd1108b752108c1fcc6528fca Author: Tanmay Shah Date: Tue Apr 28 15:18:56 2026 -0700 remoteproc: xlnx: Check remote core state commit a48df51d23138388900995add2854cda4aa68e55 upstream. The remote state is set to RPROC_DETACHED if the resource table is found in the memory. However, this can be wrong if the remote is not started, but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call to the firmware to request the state of the RPU node. If the RPU is actually out of reset and running, only then move the remote state to RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE. Signed-off-by: Tanmay Shah Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support") Reviewed-by: Beleswar Padhi Acked-by: Michal Simek Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit e5b1aaa74118e91f0c0f18b22b6f853199873db4 Author: Wasim Nazir Date: Wed Mar 18 17:19:16 2026 +0530 remoteproc: qcom: Fix leak when custom dump_segments addition fails commit ecf9fc18e62c58eae1ceb65dab2bccb8a724de2d upstream. Free allocated minidump_region 'name' in qcom_add_minidump_segments() when failing before adding the region to 'dump_segments'. Otherwise, the 'name' is not tracked and is never freed by qcom_minidump_cleanup(). Return error when adding to 'dump_segments' fails. Cc: stable@vger.kernel.org # v5.11 Fixes: 8ed8485c4f05 ("remoteproc: qcom: Add capability to collect minidumps") Reviewed-by: Mukesh Ojha Signed-off-by: Wasim Nazir Link: https://lore.kernel.org/r/20260318-rproc-memleak-v2-1-ade70ab858f2@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 98414b42530af65cb984ffc12685096a3b5e179a Author: Chuck Lever Date: Tue May 19 09:34:21 2026 -0400 SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing commit 42f5b80dda6b86e424054baf1475df686c403d5c upstream. xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly. Reported-by: Chris Mason Fixes: 2eb2b9358181 ("SUNRPC: Convert svc_tcp_sendmsg to use bio_vecs directly") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3a5c55a19cad62f2973be25fe96a1a9e7f618e8a Author: Chuck Lever Date: Thu May 14 16:56:06 2026 -0400 lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure commit 70a38f87bed7f0694fd07988b47b2db1e10d8df3 upstream. The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file. Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file") Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3f2dc01b9cb516d4727a3b9263ee58c71ca00ba9 Author: Chuck Lever Date: Thu May 14 16:56:04 2026 -0400 lockd: Plug nlm_file leak when nlm_do_fopen() fails commit f16a1513452edb532fec81e591c64c320866719c upstream. A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns. Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file") Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 31ba490c02d476a5e4f90b8845932ac9db8aa71b Author: Luxiao Xu Date: Thu May 21 15:06:32 2026 +0800 sunrpc: harden rq_procinfo lifecycle to prevent double-free commit 18d216788bef06332ff8901670ecf1ed8f6eb614 upstream. The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release. Fixes: d9adbb6e10bf ("sunrpc: delay pc_release callback until after the reply is sent") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Suggested-by: Chuck Lever Reviewed-by: Jeff Layton Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a4f878e8ecd729ccf2e50993444e217583adeace Author: Chuck Lever Date: Fri May 22 09:39:07 2026 -0400 sunrpc: wait for in-flight TLS handshake callback when cancel loses race commit d00e32f84ca1a77cb67a3fbf59f58dada95f5a21 upstream. When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED. Fixes: b3cbf98e2fdf ("SUNRPC: Support TLS handshake in the server-side TCP socket code") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 083e9c2ec7e8bb13b79c9fd7b337abdd758ecc5f Author: Chris Mason Date: Fri May 22 09:39:06 2026 -0400 sunrpc: pin svc_xprt across the asynchronous TLS handshake callback commit 4f988f3a2808fb659f3880c282041ff067acad78 upstream. svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). Fixes: b3cbf98e2fdf ("SUNRPC: Support TLS handshake in the server-side TCP socket code") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Assisted-by: kres (claude-opus-4-7) [cel: rewrote commit message to describe the actual change] Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c49df5f1e1937fcbc93f1e9a903e5db1d2269389 Author: Claudiu Beznea Date: Fri May 15 15:40:07 2026 +0300 pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP commit c1492da3939c89372929e062d731f328f7693f1e upstream. The pinctrl and GPIO core code make exceptions for the -ENOTSUPP error code. One such example is gpio_set_config_with_argument_optional(), which returns success when gpio_set_config_with_argument() returns -ENOTSUPP, but reports failure for all other error codes. Returning -EOPNOTSUPP from the pinctrl driver on the unsupported pinctrl operation may lead to boot failures when pinctrl drivers implements struct gpio_chip::set_config, the system uses GPIO hogs, and the struct gpio_chip::set_config implementation returns -EOPNOTSUPP for the unsupported operations. Return -ENOTSUPP for the unsupported pinctrl operation. Fixes: 560c633d378a ("pinctrl: renesas: rzg2l: Drop oen_read and oen_write callbacks") Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Reviewed-by: Bartosz Golaszewski Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260515124008.2947838-2-claudiu.beznea@kernel.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit ba59b96d8d21dc8729fca44a022ca5919c1848c9 Author: Abdun Nihaal Date: Tue May 19 11:20:12 2026 +0530 nvdimm/btt: Free arena sub-allocations on discover_arenas() error path commit 13fe4cd9ddd0aacb7777812328be525a11ea3fea upstream. Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ] Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260519-nvdimmleaks-v1-1-592300fb7a43@cse.iitm.ac.in Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit 7e49684d90faa34ff6d5586be658e986d9d475ac Author: Abdun Nihaal Date: Tue May 19 11:20:13 2026 +0530 nvdimm/btt: Free arenas on btt_init() error paths commit 1a6b6442a982d0ca5fb6a1a39b6f6dfd760eda57 upstream. The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ] Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260519-nvdimmleaks-v1-2-592300fb7a43@cse.iitm.ac.in Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit a58fc10adf503969fec2007b5afe8987258046c4 Author: Junrui Luo Date: Wed May 13 17:28:40 2026 +0800 jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() commit 289a2ca0c9b7eae74f93fc213b0b971669b8683d upstream. jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED. Fixes: 6866d7b3f2bb ("ext4 / jbd2: add fast commit initialization") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Fixes: e029c5f27987 ("ext4: make num of fast commit blocks configurable") Reviewed-by: Baokun Li Fixes: e029c5f279872 ("ext4: make num of fast commit blocks configurable") Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/SYBPR01MB7881663C927DE9D7BBF4D1DFAF062@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit fc5eb0962a5e50d64e711817cc24d67df2d90528 Author: Terry Bowman Date: Fri Jun 5 13:06:10 2026 -0500 cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size commit c268f949e219f9e179558e836f457f6c5fbec416 upstream. The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58 bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing 64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512, eight times the actual on-device size. header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the RAS capability iomap, overrunning the 88-byte mapping by 448 bytes. The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE (512) bytes from its source. For the CPER caller the source is struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes of kernel stack into the trace event ring buffer where userspace can read it via tracefs. Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it, bringing all iomap readers into agreement on 16 dwords. Userspace tools such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32) header_log layout in the cxl_aer_uncorrectable_error trace event. Add CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event __array and its memcpy to preserve that ABI. Both callers now pass a zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware; the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring buffer layout intact. [ dj: Replaced 64 with SZ_64 per RichardC ] Fixes: 36f257e3b0ba ("acpi/ghes, cxl/pci: Process CXL CPER Protocol Errors") Fixes: 2905cb5236cb ("cxl/pci: Add (hopeful) error handling support") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Terry Bowman Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Reviewed-by: Ben Cheatham Reviewed-by: Richard Cheng Link: https://patch.msgid.link/20260605180610.2249458-1-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 0ec5c7f03ecf66f8d31d595a2bbf439e32d0eb94 Author: Duje Mihanović Date: Sat Mar 28 21:42:16 2026 +0100 backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME commit f37f5a2ac9d3737617c08f0dc7270b42e9cad907 upstream. Boards using this backlight chip do not power the backlight off on suspend. Enable BL_CORE_SUSPENDRESUME so the chip gets powered off by the backlight core on suspend. Tested on samsung,coreprimevelte. Cc: stable@vger.kernel.org # v6.19 Signed-off-by: Duje Mihanović Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260328-ktd2801-pm-fix-v1-1-007cb103faeb@dujemihanovic.xyz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 089ea1e2faf4968d698087b4325f952ce769a50f Author: Bartosz Golaszewski Date: Thu May 21 10:36:24 2026 +0200 mfd: tps6586x: Fix OF node refcount commit 3001ed2b4e06da2276c42ace6551617065a5b1f9 upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 62f6b0879304 ("tps6586x: Add device tree support") Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260521-pdev-fwnode-ref-v1-1-88c324a1b8d2@oss.qualcomm.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit da743704c647226a45ba0082982e5363f54d3c96 Author: Shyam Prasad N Date: Thu May 14 23:38:07 2026 +0530 cifs: invalidate cfid on unlink/rename/rmdir commit f71d68d2b473e47db260c27c98212829590d8bae upstream. Today we do not invalidate the cached_dirent or the entire parent cfid when a dentry in a dir has been removed/moved. This change invalidates the parent cfid so that we don't serve directory contents from the cache. Cc: Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6222b443686525cb5a9b6a9cecf23b2e2ab23e2a Author: Sven Eckelmann Date: Fri Jul 3 22:27:13 2026 +0200 batman-adv: tt: prevent TVLV OOB check overflow commit 7a581d9aaba8c82bd6177fa36b2588eea77f6e2b upstream. A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements. Cc: stable@vger.kernel.org Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 7d1a877670bc2e901241073f022ca8d1b2f85f1c Author: Sven Eckelmann Date: Fri Jul 3 20:47:45 2026 +0200 batman-adv: mcast: avoid OOB read of num_dests header commit 38eaed28e250895d56f4b7989bd65479a511c5c3 upstream. Before the access to struct batadv_tvlv_mcast_tracker's num_dests, it is attempted to check whether enough space is actually in the network header. But instead of using offsetofend() to check for the whole size (2) which must be accessible, offsetof() of is called. The latter is always returning 0. The comparison with the network header length will always return that enough data is available - even when only 1 or 0 bytes are accessible. Instead of using offsetofend(), use the more common check for the whole header. Cc: stable@vger.kernel.org Fixes: 07afe1ba288c ("batman-adv: mcast: implement multicast packet reception and forwarding") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 777a88256d6f70672116e53400659cc417e1feaa Author: Sven Eckelmann Date: Fri Jul 3 21:04:03 2026 +0200 batman-adv: frag: fix primary_if leak on failed linearization commit 353d2c1d5492e53ae34f490a84494124dc3d3531 upstream. If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: a063f2fba3fa ("batman-adv: Don't skb_split skbuffs with frag_list") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 5a82c558098889cc8bfff85cc62f563833205d91 Author: Sven Eckelmann Date: Sat Jul 4 09:46:09 2026 +0200 batman-adv: clean untagged VLAN on netdev registration failure commit 8669a550c752d86baebc5fdc83b8ff35c4372c0e upstream. When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object. Cc: stable@vger.kernel.org Fixes: 5d2c05b21337 ("batman-adv: add per VLAN interface attribute framework") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 08047838817561cef33ada9774a2a4663d499ecb Author: Sven Eckelmann Date: Fri Jul 3 20:28:31 2026 +0200 batman-adv: frag: free unfragmentable packet commit 6b628425aed49a1c7a4ffc997583840fc582d32b upstream. The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function. Cc: stable@vger.kernel.org Fixes: ee75ed88879a ("batman-adv: Fragment and send skbs larger than mtu") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit ae8355b24abec43328c8bf8187645a5310e90a43 Author: Sven Eckelmann Date: Thu Jul 2 20:45:24 2026 +0200 batman-adv: fix VLAN priority offset commit fdb3be00ba4dafa313e699d6b5b90d13f22f3f25 upstream. The batadv_skb_set_priority() receives an SKB with the inner ethernet header at position "offset". When it tries to extract the IPv4 and IPv6 header, it needs to skip the ethernet header to get access to the IP header. But for VLAN header, it performs the access with the struct vlan_ethhdr. This struct contains both both the ethernet header and the VLAN header. It is therefore incorrect to skip over the whole vlan_ethhdr size to get access to the vlan_ethhdr. Cc: stable@vger.kernel.org Fixes: c54f38c9aa22 ("batman-adv: set skb priority according to content") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit aba1cf21954e64c36afb966b754adad2b0b8aa48 Author: Sven Eckelmann Date: Thu Jul 2 21:06:23 2026 +0200 batman-adv: tt: avoid request storms during pending request commit 27c7d40008231ae4140d35501b60087a9de2d2c3 upstream. batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is "ret == false". But the actual implementation is checking for "ret == true". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms. Cc: stable@vger.kernel.org Fixes: 335fbe0f5d25 ("batman-adv: tvlv - convert tt query packet to use tvlv unicast packets") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 64fd0b0dbb5210bd071b82fce30d65218f5953b5 Author: Sven Eckelmann Date: Thu Jul 2 19:32:40 2026 +0200 batman-adv: dat: fix tie-break for candidate selection commit 98052bdaf6ac1639a63ffc10244eeeab1f62ed2b upstream. The original version of the candidate selection for DAT attempted to compare both candidate and max_orig_node to identify which has the smaller MAC address. This comparison is required as tie-break when a hash collision happened. But the used function returned 0 when the function was not equal and a non-zero value when it was equal. As result, the actually selected node was dependent on the order of entries in the orig_hash and not actually on the mac addresses. The last originator in the hash collision would always win. To have a proper ordering, it must diff the actual MAC address bytes and reject the candidate when the diff is not smaller than 0. Cc: stable@vger.kernel.org Fixes: 785ea1144182 ("batman-adv: Distributed ARP Table - create DHT helper functions") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit dbeb4145d9778f922f459935da9a027750765a69 Author: Sven Eckelmann Date: Thu Jul 2 11:46:21 2026 +0200 batman-adv: ensure minimal ethernet header on TX commit 49df66b7993c80b80c7eb9a84ba5b3410c8296a0 upstream. As documented in commit 8bd67ebb50c0 ("net: bridge: xmit: make sure we have at least eth header len bytes"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len. Cc: stable@vger.kernel.org Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Reported-by: Sashiko Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 4407ff3af469356f9641c4a6e7072309bae86bea Author: Sven Eckelmann Date: Sun Jun 28 10:37:07 2026 +0200 batman-adv: dat: ensure accessible eth_hdr proto field commit 26560c4a03dc4d607331600c187f59ab2df5f341 upstream. When batadv_get_vid() accesses the proto field of the ethernet header, it is not checking if the data itself is accessible. The caller is responsible for it. But in contrast to other call sites, batadv_dat_get_vid() and its caller didn't make sure this is true. This could have caused an out-of-bounds access. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit f4fb97ecf677cd9c3aa4f3bfc6fbf5b0e4bdbbbf Author: Sven Eckelmann Date: Sun Jun 28 08:45:41 2026 +0200 batman-adv: bla: reacquire gw address after skb realloc commit cdf3b5af2bc4431e58629e8ad2086b1e9185c761 upstream. The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. Cc: stable@vger.kernel.org Fixes: 9e794b6bf4a2 ("batman-adv: drop unicast packets from other backbone gw") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 059a70e1d12d6d99310e0599d37b0323557569a8 Author: Sven Eckelmann Date: Sun Jun 28 08:45:41 2026 +0200 batman-adv: dat: acquire ARP hw source only after skb realloc commit 48067b2ae4504500a7093d9e1e16b42e70330480 upstream. The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. Cc: stable@vger.kernel.org Fixes: b61ec31c8575 ("batman-adv: Snoop DHCPACKs for DAT") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 9a7b7248798123efbd5fafe58461d57c7cc718af Author: Sven Eckelmann Date: Sun Jun 28 08:35:35 2026 +0200 batman-adv: access unicast_ttvn skb->data only after skb realloc commit 7141990add3f75436f2933cb310654cad3b1e3e9 upstream. The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: c018ad3de61a ("batman-adv: add the VLAN ID attribute to the TT entry") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b031fc97e1993d29d6c3a0e86a99140528cf31e8 Author: Sven Eckelmann Date: Sun Jun 28 06:44:13 2026 +0200 batman-adv: retrieve ethhdr after potential skb realloc on RX commit 035e1fed892d3d06002a73ff73668f618a514644 upstream. pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Fixes: c78296665c3d ("batman-adv: Check skb size before using encapsulated ETH+VLAN header") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 916dac5f2944f63f07f7b501acbea6737dbbed0e Author: Sven Eckelmann Date: Sun Jun 28 08:45:41 2026 +0200 batman-adv: gw: acquire ethernet header only after skb realloc commit 77880a3be88d378d60cc1e8f8ec70430e2ed0518 upstream. The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. Cc: stable@vger.kernel.org Fixes: 6c413b1c22a2 ("batman-adv: send every DHCP packet as bat-unicast") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit f79dff8c721bbb1f3fc312ea55e0551c2cc28801 Author: Sumanth Korikkar Date: Mon Jul 6 12:46:31 2026 +0200 s390/perf_cpum_cf: Add missing array_index_nospec() to __hw_perf_event_init() commit 49145bce539117db4b6e9e83c0e5ef528e361050 upstream. ev variable is userspace controlled via event->attr.config and used as an array index after bounds checking, but without speculation barriers. Add the missing array_index_nospec() call to prevent speculative execution. Cc: stable@vger.kernel.org Fixes: 212188a596d1 ("[S390] perf: add support for s390x CPU counters") Signed-off-by: Sumanth Korikkar Reviewed-by: Ilya Leoshkevich Acked-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit cabcfbc069d804e4fb4215cf1167c531ed2a6394 Author: Rafael J. Wysocki Date: Tue Jul 7 19:19:55 2026 +0200 cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF() commit 27d80e0f8b8dff97503fc0061754b1d3800cb961 upstream. Setting cpu->capacity_perf to cpu->pstate.max_pstate_physical in the "no turbo" case is inconsistent with what happens elsewhere in the driver and causes arch_scale_cpu_capacity() to be incorrect. It also skews arch_scale_freq_capacity() which ends up differing from 1024 for the guaranteed P-state. Address that by setting capacity_perf to HWP_GUARANTEED_PERF() in the "no turbo" case. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Rafael J. Wysocki Tested-by: Ricardo Neri Cc: All applicable Link: https://patch.msgid.link/12928972.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit a18afd69408cf53035b4f1483f8c0d7de1aa813b Author: Zhongqiu Han Date: Tue Jun 16 23:47:33 2026 +0800 cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf() path commit 9ef450ca74e43dacf9a2a15db7a851052c78dcf0 upstream. The need_freq_update flag makes sugov_should_update_freq() return true regardless of the rate_limit_us throttling, and is cleared in sugov_update_next_freq(). sugov_update_single_freq() and sugov_update_shared() go through that helper, so the flag does not persist there. However, sugov_update_single_perf(), used by drivers implementing the .adjust_perf() callback (e.g. intel_pstate or amd-pstate in passive mode) calls cpufreq_driver_adjust_perf() directly and never goes through sugov_update_next_freq(), so the need_freq_update flag is not cleared in that path. Before commit 75da043d8f88 ("cpufreq/sched: Set need_freq_update in ignore_dl_rate_limit()"), this was effectively harmless because sugov_should_update_freq() still honored the rate limit even when need_freq_update was set. After that change, the flag forces sugov_should_update_freq() to always return true, so once set, it stays effective indefinitely on the .adjust_perf() path. As a result, cpufreq_driver_adjust_perf() gets called on every scheduler utilization update (with the runqueue lock held) rather than being throttled by rate_limit_us, even if the driver itself may skip redundant hardware updates. Clear need_freq_update at the end of the adjust_perf path as well. Fixes: 75da043d8f88 ("cpufreq/sched: Set need_freq_update in ignore_dl_rate_limit()") Signed-off-by: Zhongqiu Han Reviewed-by: Hongyan Xia Reviewed-by: Christian Loehle Cc: All applicable [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260616154733.2405236-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fb3b76b5ad2ebad63dd76f8b65b624eaf638b73f Author: Sandipan Das Date: Fri Jul 10 16:15:27 2026 +0530 perf/x86/amd/lbr: Fix kernel address leakage commit 2a892294b83f541115c94b0bb637f39bef187657 upstream. A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel. E.g. $ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested. Fixes: f4f925dae741 ("perf/x86/amd/lbr: Add LbrExtV2 hardware branch filter support") Reported-by: Ian Rogers Signed-off-by: Sandipan Das Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Cc: Peter Zijlstra Link: https://patch.msgid.link/a898a29725f6b2f30518354cdc2e432db66c43cf.1783680119.git.sandipan.das@amd.com Signed-off-by: Greg Kroah-Hartman commit 2e706be56f418718bb3ae66c0aa94f9b61150e6d Author: Sandipan Das Date: Fri Jul 10 22:04:49 2026 +0530 perf/x86/amd/brs: Fix kernel address leakage commit 47915e855fb38b42133e31ba917d99565f862154 upstream. A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_BRS (Zen 3 only), perf can still report entries such as SYSRET/interrupt returns for which the branch-from addresses are in the kernel. E.g. $ perf record -j any,u -c 4000 -e branch-brs -o - -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//- 0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//- 0xffffffff810001c4/0x72e2d94ffa1b/-/-/-/0//- ... BRS provides no hardware branch filtering, so privilege level filtering is performed entirely in software. However, amd_brs_match_plm() only validates the branch-to address against the requested privilege levels. For branches from the kernel to user space, the branch-from address is left unchecked and is leaked. Extend the software filter to also validate the branch-from address, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested. Fixes: 8910075d61a3 ("perf/x86/amd: Enable branch sampling priv level filtering") Reported-by: Sashiko Signed-off-by: Sandipan Das Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Cc: Peter Zijlstra Cc: Stephane Eranian Link: https://patch.msgid.link/f05931c4f89a146c364bd5dc6b8170b1ac611c65.1783701239.git.sandipan.das@amd.com Closes: https://lore.kernel.org/all/20260710110235.F3FD81F000E9@smtp.kernel.org/ Signed-off-by: Greg Kroah-Hartman commit 64193ed819db31b9548074daa6b3948c317f59c6 Author: Thorsten Blum Date: Sun Jun 21 19:00:10 2026 +0200 x86/boot: Reject too long acpi_rsdp= values commit d130041a7b96f79cd4c7079a6c2431a6db4c9619 upstream. cmdline_find_option() returns the full length of the parsed acpi_rsdp= value. get_cmdline_acpi_rsdp() then silently truncates values which do not fit in the val[] buffer. Prevent boot_kstrtoul() from parsing a truncated value and then the kernel from silently using the wrong RSDP address, see discussion in Link:. Issue a warning so that the user is aware that s/he supplied a malformed value and can get feedback instead of silent crashes. [ bp: Make commit message more precise. ] Fixes: 3c98e71b42a7 ("x86/boot: Add "acpi_rsdp=" early parsing") Signed-off-by: Thorsten Blum Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260617130417.36651-4-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 4dad7e870c7e5178f71b5e1e4f67934b9e8cc207 Author: Thorsten Blum Date: Mon Jul 13 21:49:25 2026 +0200 x86/boot: Validate console=uart8250 baud rate to fix early boot hang commit ffa0aa5b625fe0bed7463ac613f8b06676ff4542 upstream. When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang. Fixes: ce0aa5dd20e4 ("x86, setup: Make the setup code also accept console=uart8250") Signed-off-by: Thorsten Blum Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260713194924.126472-3-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit e5158ff53fdff9c229bf13aa5f75eb17cdcfcd2d Author: Tycho Andersen (AMD) Date: Tue Jul 7 09:00:33 2026 -0600 x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN" commit 4c2509f3b79756679a02bea649c6a7501b58f52c upstream. Revert 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"). Section 8.8 of the SNP spec says: Before invoking SNP_INIT_EX with INIT_RMP set to 1, software must ensure that no CPUs contain dirty cache lines for the memory containing the RMP. Cachelines can be moved from cache to cache in a dirty state. The wbinvd_on_all_cpus() before SNP_INIT_EX flushes the caches for each CPU, but if the IPIs for WBINVD race with this dirty cacheline movement, it is possible that they may not get flushed, violating the firmware requirement. Doing wbinvd_on_all_cpus() before setting SNPEn is safer since the RMP table is not yet in use. [ Heroically bisected by Srikanth. ] [ bp: Massage commit message. ] Fixes: 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN") Reported-by: Srikanth Aithal Signed-off-by: Tycho Andersen (AMD) Signed-off-by: Borislav Petkov (AMD) Tested-by: Srikanth Aithal Reviewed-by: Tom Lendacky Cc: Link: https://patch.msgid.link/20260707150033.2364758-1-tycho@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8a2a0b911cd6ebf61217b552d758b0c2a22cad82 Author: Mario Limonciello Date: Tue Jun 23 07:15:05 2026 -0700 x86/video: Only fall back to vga_default_device() without screen info commit 596b3678326d3d1aed7c19423b6746f1ce09688a upstream. Some multi GPU systems may have a VGA compatible device, but that might not be used for display. If due to enumeration order this device is found before the one actually used for display then multiple devices may show the boot_display attribute, confusing userspace. When screen info is valid, use it exclusively to find the primary device so that only the device backing the framebuffer is reported. Only when no framebuffer has been set up does it make sense to fall back to the default VGA device. This ensures at most one primary graphics device, preferably the one with the framebuffer. Fixes: ad90860bd10ee ("fbcon: Use screen info to find primary device") Closes: https://lore.kernel.org/linux-pci/20260618081803.2790848-1-aaron.ma@canonical.com/#t Reported-by: Aaron Ma Suggested-by: Thomas Zimmermann Signed-off-by: Mario Limonciello Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Thomas Zimmermann Tested-by: Aaron Ma Cc: Link: https://patch.msgid.link/20260623141505.1816786-1-mario.limonciello@amd.com Signed-off-by: Greg Kroah-Hartman commit e8adac69d1bdf035ef97cc914e845acd4ef08e28 Author: Ali Ahmet MEMIS Date: Sun Apr 26 08:09:28 2026 -0700 tools/power/x86/intel-speed-select: Harden daemon pidfile open commit 607af438e6430893a822964c841a1994b33acccc upstream. Avoid symlink-based pidfile clobbering by opening the pidfile with O_NOFOLLOW and validating it with fstat() before locking/writing. The daemon currently uses a fixed pidfile path under /tmp. A local unprivileged user can pre-create a symlink at that path and cause a root-run daemon instance to write into an attacker-chosen file. Fixes: 7fd786dfbd2c ("tools/power/x86/intel-speed-select: OOB daemon mode") Signed-off-by: Ali Ahmet MEMIS Signed-off-by: Srinivas Pandruvada Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2ff8156fd500d54c61430b6834137fd0a07047ce Author: Guangshuo Li Date: Thu Apr 16 00:26:27 2026 +0800 mfd: sm501: Fix reference leak on failed device registration commit 8c2f0b42fc252e1bf1c7746447091a468e784ca1 upstream. When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: b6d6454fdb66f ("[PATCH] mfd: SM501 core driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260415162627.3558789-1-lgs201920130244@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 263ccdd627caeda6e980ed3c6e32bb4fd6b380b1 Author: Armin Wolf Date: Mon May 25 01:55:53 2026 +0200 leds: uleds: Fix potential buffer overread commit c19fe864f667afc49d1391d764e20b66555bcf7a upstream. The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated. Cc: stable@vger.kernel.org Fixes: e381322b0190 ("leds: Introduce userspace LED class driver") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260524235553.189134-1-W_Armin@gmx.de Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit c9a691350e28e41c2b15c0ec43b9dbadb974a925 Author: Ondrej Mosnacek Date: Tue Jul 14 14:57:59 2026 +0200 selinux: fix incorrect execmem checks on overlayfs commit 9fe595fad54d4ac6a402edb3f60bec859d52cea6 upstream. The commit fixing the overlayfs mmap() and mprotect() access checks failed to skip the execmem check in __file_map_prot_check() for the case where the "mounter check" is being performed. This check should be performed only against the credentials of the task that is calling mmap()/mprotect(), since it doesn't pertain to the file itself, but rather just gates the ability of the calling task to get an executable memory mapping in general. The purpose of the "mounter check" is to guard against using an overlayfs mount to gain file access that would otherwise be denied to the mounter. For execmem this is not relevant, as there is no further file access granted based on it (notice that the file's context is not used as the target in the check), so checking it also against the mounter credentials would be incorrect. Fix this by passing a boolean to [__]file_map_prot_check() and selinux_mmap_file_common() that indicates if we are doing the "mounter check" and skiping the execmem check in that case. Since this boolean also indicates if we use current_cred() or the mounter cred as the subject, also remove the "cred" argument from these functions and determine it based on the boolean and the file struct. Cc: stable@vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Signed-off-by: Ondrej Mosnacek Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 37d642b37ccdc31e1947c2ebc8dc38f03d4a0ceb Author: Tristan Madani Date: Thu Jun 25 23:53:36 2026 +0000 selinux: avoid sk_socket dereference in selinux_sctp_bind_connect() commit 56acfeb10019e200ab6787d01f8d7cbe0f01526f upstream. selinux_sctp_bind_connect() dereferences sk->sk_socket to pass a struct socket * to selinux_socket_bind() and selinux_socket_connect_helper(). However, when the hook is invoked from the ASCONF softirq path (sctp_process_asconf), there is no file reference guaranteeing that sk->sk_socket is non-NULL. The setsockopt callers (bindx, connectx, set_primary, sendmsg connect) hold a file reference and are not affected. Both selinux_socket_bind() and selinux_socket_connect_helper() immediately resolve sock->sk, never using the struct socket * for anything else. Refactor the inner logic into helpers that take a struct sock * directly so that selinux_sctp_bind_connect() never needs to touch sk->sk_socket at all. Cc: stable@vger.kernel.org Fixes: d452930fd3b9 ("selinux: Add SCTP support") Suggested-by: Stephen Smalley Signed-off-by: Tristan Madani Reviewed-by: Stephen Smalley Tested-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 646ebbc5f2ff9147d084e1213143f091026a611c Author: Stephen Smalley Date: Thu Jun 18 13:55:14 2026 -0400 selinux: check connect-related permissions on TCP Fast Open commit 44c74d27d1b9aaa99fa8a83640c1223575262b80 upstream. Similar to Landlock, SELinux was not updated when TCP Fast Open support was introduced to ensure connect-related permissions are checked when using TCP Fast Open. Update its socket_sendmsg() hook to call selinux_socket_connect() when MSG_FASTOPEN is passed. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-security-module/20260616201615.275032-1-hexlabsecurity@proton.me/ Link: https://lore.kernel.org/linux-security-module/20260617180526.15627-2-matthieu@buffet.re/ Reported-by: Bryam Vargas Reported-by: Matthieu Buffet Reported-by: Mikhail Ivanov Signed-off-by: Stephen Smalley Tested-by: Bryam Vargas Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit fe11d6ce19b2b2d01e2e324f375280d1aa38b75d Author: Wang Jun <1742789905@qq.com> Date: Fri Mar 27 08:12:25 2026 +0800 soc: fsl: qe: panic on ioremap() failure in qe_reset() commit a0fe29d20e7822182e12324905af5115c1b3aed3 upstream. When ioremap() fails in qe_reset(), the global pointer qe_immr remains NULL, leading to a subsequent NULL pointer dereference when the pointer is accessed. Since this happens early in the boot process, a failure to map a few bytes of I/O memory indicates a fatal error from which the system cannot recover. Follow the same pattern as qe_sdma_init() and panic immediately when ioremap() fails. This avoids a silent NULL pointer dereference later and makes the error explicit. Fixes: 986585385131 ("[POWERPC] Add QUICC Engine (QE) infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Wang Jun <1742789905@qq.com> Link: https://lore.kernel.org/r/tencent_FED49CF5331CC0C7910618883332A08E2606@qq.com [chleroy: Rearranged change to reduce churn] Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Greg Kroah-Hartman commit 9b3325f5a9fb6e3702daa417778202a1163f1ed5 Author: Siddharth Vadapalli Date: Fri May 1 18:10:54 2026 +0530 soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io/proxy commit b920352cfd2b0fcd1249ff006618c939b64fc8f7 upstream. k3_ringacc_ring_pop_tail_io() and k3_ringacc_ring_pop_tail_proxy() incorrectly use K3_RINGACC_ACCESS_MODE_POP_HEAD instead of K3_RINGACC_ACCESS_MODE_POP_TAIL. This will result in ring elements being popped in the reverse order of that which the caller expects. Fix this. Fixes: 3277e8aa2504 ("soc: ti: k3: add navss ringacc driver") Cc: stable@vger.kernel.org Signed-off-by: Siddharth Vadapalli Reviewed-by: Hari Prasath Gujulan Elango Link: https://patch.msgid.link/20260501124129.362192-1-s-vadapalli@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Greg Kroah-Hartman commit 419d7d9306491f3e0e417cf794844c73cabee090 Author: Arunpravin Paneer Selvam Date: Thu Jul 9 18:40:50 2026 +0530 gpu/buddy: bail out of try_harder when alignment cannot be honoured commit 56bc6384314fb9ae98975fb2af8b143097ede3dc upstream. The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Suggested-by: Christian König Cc: Matthew Auld Cc: Christian König Cc: Timur Kristóf Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld Tested-by: John Olender Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com Signed-off-by: Greg Kroah-Hartman commit 8559b1501f77a5b5d003790bec170ca449e0c674 Author: Guangshuo Li Date: Mon Apr 13 22:15:26 2026 +0800 gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path commit e75717f9aec04355777be41070890c6a815c76df upstream. After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path. Fixes: f4c5cf88fbd50 ("gpu: host1x: Provide a proper struct bus_type") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Acked-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260413141526.2961841-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit 392d033fd372268015bc5a54ba7c593ba44940d1 Author: Pablo Neira Ayuso Date: Thu Jul 9 13:40:25 2026 +0200 netfilter: flowtable: use correct direction to set up tunnel route commit 90941d9c925d66a482c9121919ec3546a6988c16 upstream. The layer 2 encapsulation and layer 3 tunnel information in the xmit path is taken from the other tuple, because the tunnel information that is included in the tuple for hashtable lookups is also used to perform the egress encapsulation in the transmit path. This patch uses the correct direction when setting up the tunnel, the original proposed patch to address this fix uses the reversed direction. While at it, remove the redundant check to call dst_release() to drop the reference on the dst that was obtained from the forward path, which is not useful in the direct xmit path unless tunneling is performed. Fixes: fa7395c02d95 ("netfilter: flowtable: support IPIP tunnel with direct xmit") Cc: stable@vger.kernel.org Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 4ac981a8b7ce7aec99a52d08f8a8953e8e120067 Author: Xiang Mei (Microsoft) Date: Wed Jul 8 18:11:50 2026 +0000 netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() commit 86f3ce81dd2b4b0aa2c3016c989a943e4b1b643d upstream. br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f ("ipv6: Fix dangling pointer when ipv6 fragment"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 764dd163ac92 ("netfilter: nf_conntrack_bridge: add support for IPv6") Cc: stable@vger.kernel.org Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit ec88fa71c82072e9189983b05b499d3507550271 Author: Wyatt Feng Date: Sat Jun 13 18:27:15 2026 +0800 netfilter: xt_nat: reject unsupported target families commit 5d1a2240935ea47e2673d0ea17fdb058e4dc91dd upstream. xt_nat SNAT and DNAT target handlers assume IP-family conntrack state is present and can dereference a NULL pointer when instantiated from an unsupported family through nft_compat. A bridge-family compat rule can therefore trigger a NULL-dereference in nf_nat_setup_info(). Reject non-IP families in xt_nat_checkentry() so unsupported targets cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT compat users and leave the runtime fast path unchanged. [ The crash was fixed via 9dbba7e694ec ("netfilter: nft_compat: ebtables emulation must reject non-bridge targets"), so this patch is no longer critical. Nevertheless, NAT is only relevant for ipv4/ipv6, so this extra family check is a good idea in any case. ] Fixes: c7232c9979cb ("netfilter: add protocol independent NAT core") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 4301ae9ce3d4cc8f99043b20b6685691b28a65ca Author: Yizhou Zhao Date: Tue Jul 7 19:00:14 2026 +0800 netfilter: ecache: fix inverted time_after() check commit b06163ce52ec0561f202fbfb9b08090cb61f512e upstream. ecache_work_evict_list() redelivers DESTROY events for conntracks that were moved to the per-netns dying_list after event delivery failed. It sets a 10ms deadline: stop = jiffies + ECACHE_MAX_JIFFIES but then tests: time_after(stop, jiffies) This condition is true while the deadline is still in the future, so the worker returns STATE_RESTART after the first successful redelivery in the usual case. ecache_work() maps STATE_RESTART to delay 0, which turns the redelivery path into one dying conntrack per workqueue dispatch and makes the sent > 16 batching/cond_resched() path effectively unreachable. A conntrack netlink listener whose receive queue is congested can make DESTROY event delivery fail with -ENOBUFS. With sustained conntrack churn, entries then accumulate on the dying_list and are only drained at the degraded one-entry-per-dispatch rate once delivery succeeds again, wasting CPU on back-to-back workqueue reschedules and prolonging conntrack memory/resource pressure. In a KASAN QEMU test with CONFIG_NF_CONNTRACK_EVENTS=y and nf_conntrack.enable_hooks=1, a congested DESTROY listener caused 8192 nf_ct_delete() calls to return false and move entries to the dying_list. After closing the listener, the unfixed kernel needed 7670 ecache_work() entries to destroy 7669 conntracks. With this change, the same 8192 entries were destroyed by 2 ecache_work() entries. Swap the comparison so the worker restarts only after the deadline has expired. Fixes: 2ed3bf188b33 ("netfilter: ecache: use dedicated list for event redelivery") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit b7a1626c28badec4559e8a97665baf3b6e015fc0 Author: Florian Westphal Date: Fri Jul 10 12:44:41 2026 +0200 netfilter: xt_physdev: masks are not c-strings commit f468c48d488d0ea2df3422b3e1dfafae1611e853 upstream. ... and must not be subjected to the 'nul terminated' constraint. If the interface name is 15 characters long, the mask is 16-bytes '0xff' (to cover for \0) and the valid device name is rejected. Fixes: 8df772afc9d0 ("netfilter: x_physdev: reject empty or not-nul terminated device names") Cc: stable@vger.kernel.org Closes: https://bugs.launchpad.net/neutron/+bug/2159935 Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 6ff07ac5405bea4d4ead3559fc123f987576424a Author: Yizhou Zhao Date: Wed Jul 8 13:27:28 2026 +0800 netfilter: nf_conncount: fix zone comparison in tuple dedup commit f62c41b4910e65da396ec9a8c40c1fe7fe82e449 upstream. The "already exists" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons. Fixes: 21ba8847f857 ("netfilter: nf_conncount: Fix garbage collection with zones") Fixes: b36e4523d4d5 ("netfilter: nf_conncount: fix garbage collection confirm race") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 0880c4ed122d0cddc9f29a2b28f055d1f24f0fca Author: Pablo Neira Ayuso Date: Tue Jun 30 11:40:56 2026 +0200 netfilter: flowtable: support IPIP tunnel with direct xmit commit fa7395c02d95e51bad2952325d2d6503bfbad437 upstream. The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei . Fixes: d30301ba4b07 ("netfilter: flowtable: Add IPIP tx sw acceleration") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Reported-by: Zhengyang Chen Reported-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Acked-by: Lorenzo Bianconi Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit ecb78fbb03d3f86e2e93767875e273308086a424 Author: Pablo Neira Ayuso Date: Tue Jun 30 11:40:54 2026 +0200 netfilter: flowtable: use dst in this direction when pushing IPIP header commit c328b90c17fc5fa7786503695152880b2afb9326 upstream. When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage. Fixes: d30301ba4b07 ("netfilter: flowtable: Add IPIP tx sw acceleration") Fixes: 93cf357fa797 ("netfilter: flowtable: Add IP6IP6 tx sw acceleration") Cc: stable@vger.kernel.org Acked-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 00bdce2fda7e430d24cfbc96764a1b96deb31f82 Author: Xiang Mei Date: Sun Jul 5 16:36:29 2026 -0700 netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag commit 3b08fed5b7e0d5e3a25d73ef3ba09cd33ade16c9 upstream. nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: skb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the "not set" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 0e76e3e886cc9ee027337d5ad39cb96f57b7bdc7 Author: Florian Westphal Date: Wed Jul 1 07:44:17 2026 +0200 netfilter: nf_nat_sip: reload possible stale data pointer commit 77e43bcb7ec177e293a5c3f1b91a2c5aebfb6c68 upstream. quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): if (skb_ensure_writable(skb, skb->len)) { nf_ct_helper_log(skb, ct, "cannot mangle packet"); return NF_DROP; } uh = (void *)skb->data + protoff; uh->dest = ct_sip_info->forced_dport; if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream. Fixes: 7266507d8999 ("netfilter: nf_ct_sip: support Cisco 7941/7945 IP phones") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit e74f9680e1b64872a51cc7b5bda1edaaa08aa51f Author: Florian Westphal Date: Tue Jun 16 13:26:26 2026 +0200 netfilter: nft_set_pipapo: don't leak bad clone into future transaction commit 47e65eff50691f0a5b79d325e28d83ec1da43bcf upstream. On memory allocation failure the cloned nft_pipapo_match can enter a bad state: - some fields can have their lookup tables resized while others did not - bits might have been toggled - scratch map can be undersized which also means m->bsize_max can be lower than what is required This means that the next insertion in the same batch can trigger out-of-bounds writes. Furthermore, a failure in the first can result in the bad clone to leak into the next transaction because the abort callback is never executed in this case (the upper layer saw an error and no attempt to allocate a transactional request was made). Record a state for the nft_pipapo_match structure: - NEW (pristine clone) - MOD (modified clone with good state) - ERR (potentially bogus content) Then make it so that deletes and insertions fail when the clone entered ERR state. In case the very first insert attempt results in an error, free the clone right away. Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Cc: stable@vger.kernel.org Reported-and-tested-by: Seesee Reviewed-by: Stefano Brivio Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit b843a96252f672332837ea2ecb7c8db0acf68e20 Author: Pablo Neira Ayuso Date: Fri Jun 26 13:24:49 2026 +0200 netfilter: nf_conntrack_sip: validate skb_dst() before accessing it commit e5e24a365a5e024efef63cc49abb345fbd4852c5 upstream. tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash. Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action") Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Cc: stable@vger.kernel.org Reported-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit f68305267ebda7e839b5e8f77e8d77535a3d5a0f Author: Theodor Arsenij Larionov-Trichkine Date: Mon Jun 29 12:53:11 2026 +0200 netfilter: nft_fib: reject fib expression on the netdev egress hook commit d07955dd34ecae17d35d8c7d0a273a3fba653a8c upstream. A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks. Fixes: 42df6e1d221d ("netfilter: Introduce egress hook") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netfilter-devel/ajxsjcDOnwllMfoR@strlen.de/ Signed-off-by: Theodor Arsenij Larionov-Trichkine Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 47b3af24de5fbed4bf2952de0f5294ef1a338a26 Author: Haoze Xie Date: Mon Jun 8 13:43:44 2026 +0800 netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst commit c9c9b37f8c5505224e8d206184df3bb668ee00cf upstream. The br_netfilter fake rtable is embedded in struct net_bridge and is attached to bridged packets with skb_dst_set_noref(). If such a packet is queued to NFQUEUE, __nf_queue() upgrades that fake dst with skb_dst_force(). At that point the queued skb can hold a real dst reference after bridge teardown has started. The problem is not that every bridged packet needs its own dst reference. The problem is that NFQUEUE can keep the bridge private fake dst alive after unregister begins. Fix this by keeping the bridge fake dst model unchanged and pinning the bridge master device only while the packet sits in NFQUEUE. Record the bridge device in nf_queue_entry when the queued skb carries a bridge fake dst, take a device reference for the queue lifetime, and drop it when the queue entry is freed. Also make sure queued entries are reaped when that bridge device goes down, and drop the redundant nf_bridge_info_exists() test from the fake dst detection. This keeps netdev_priv(br->dev) alive until verdict completion, so the embedded fake rtable and its metrics backing storage cannot be freed out from under dst_release(). It also avoids the constant refcount bump and avoids using ipv4-specific dst helpers for IPv6 bridge traffic. Fixes: 34666d467cbf ("netfilter: bridge: move br_netfilter out of the core") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Haoze Xie Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 5b2d4f0010018a7aa3495aa1dbf1b7a34011e7aa Author: Wyatt Feng Date: Thu Jun 11 15:21:42 2026 +0800 netfilter: xt_cluster: reject template conntracks in hash match commit 5feba91006ec92da57acc1cc2e34df623b98541e upstream. xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state. Fixes: 0269ea493734 ("netfilter: xtables: add cluster match") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 29e06c8f616c67784ddd5afe7887dc6ba53cd68e Author: David Carlier Date: Sat Apr 11 19:57:21 2026 +0100 netfilter: nfnl_cthelper: apply per-class values when updating policies commit d738feccb98cb224ebabecb703e98f5008276bff upstream. When a userspace conntrack helper with multiple expectation classes is updated via nfnetlink, every class ends up with the first class's max_expected and timeout values. nfnl_cthelper_update_policy_all() validates each new policy into the corresponding slot of the temporary new_policy array, but the second loop that commits the values into the live helper dereferences new_policy as a pointer instead of indexing it, so every iteration reads new_policy[0] regardless of i. An update that changes per-class values is silently collapsed onto class 0's values with no error returned to userspace. Index the temporary array by i in the commit loop so each class gets its own validated values. Fixes: 2c422257550f ("netfilter: nfnl_cthelper: fix runtime expectation policy updates") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit eeef3b81f449560653662df2dde6f6fe247c5365 Author: Muhammad Bilal Date: Tue May 19 17:23:28 2026 -0400 netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read commit ef6400ca25a13fd6dedbe8ef4a1d0979bbbfe88a upstream. parse_dcc() treats data_end as an inclusive end pointer, but its only caller passes data_limit = ib_ptr + datalen, which points one past the last valid byte. The newline search loop iterates while tmp <= data_end, so when no newline is present, *tmp is read at tmp == data_end, one byte beyond the region filled by skb_header_pointer(). irc_buffer is kmalloc'd as MAX_SEARCH_SIZE + 1 bytes and datalen is capped at MAX_SEARCH_SIZE, so the stray read does not fault. The byte is uninitialized or stale; if it contains an ASCII digit, simple_strtoul will consume it and produce a wrong DCC IP or port in the conntrack expectation. The extra allocation byte is also a fragile guard: if the cap or allocation size changes, this becomes a real out-of-bounds read. Change the loop and its post-loop check to use strict less-than, consistent with the caller's exclusive-end convention. Update the function comment accordingly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 214af790e3a33ab73587de4c925c60a550eae9c6 Author: Srinivas Kandagatla Date: Tue Jun 16 18:02:57 2026 +0100 ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback commit 2e9261761b35f0b67b7487688cd1365f535be0b3 upstream. When q6apm_free_fragments() is called it frees rx_data.buf/tx_data.buf and sets them to NULL under graph->lock. A late DSP buffer-done response can race with this: graph_callback() passes the !graph->ar_graph guard (not yet NULL), acquires the lock, but then dereferences a now-NULL buf pointer to read buf[token].phys, crashing at virtual address 0x10. Add a NULL check for buf inside the mutex-protected section in both the write-done (DATA_CMD_RSP_WR_SH_MEM_EP_DATA_BUFFER_DONE_V2) and read-done (DATA_CMD_RSP_RD_SH_MEM_EP_DATA_BUFFER_V2) handlers and bail out cleanly if buffers have already been freed. This problem is only shown up recently while apr bus was updated to process the commands per service rather from single global queue. Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Cc: Stable@vger.kernel.org Assisted-by: Claude:claude-4-6-sonnet Reported-by: Val Packett Closes: https://lore.kernel.org/all/133ced18-1aa9-475d-80d8-6120678bdde4@packett.cool/ Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260616170257.9381-1-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 03009465312ca35137f84cf84c95686137608deb Author: Cássio Gabriel Date: Wed May 27 10:41:48 2026 -0300 ASoC: mediatek: mt8183: Release reserved memory on cleanup commit bee65e00c0924ebecf97718d95dcf4a05ee36471 upstream. The MT8183 AFE probe can assign reserved memory with of_reserved_mem_device_init(), but the assignment is never released on driver removal or later probe failures. Register a devm cleanup action so the reserved memory assignment is released consistently, matching newer Mediatek AFE drivers. Fixes: ec4a10ca4a68 ("ASoC: mediatek: use reserved memory or enable buffer pre-allocation") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260527-asoc-mt8183-probe-cleanup-v1-1-4f4f5593c8d1@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 80506fcac597770066cc95f6cd446d9f71ba8ce9 Author: Cássio Gabriel Date: Wed May 27 10:41:49 2026 -0300 ASoC: mediatek: mt8183: Check runtime resume during probe commit f0334fbfd107682d0c95f3f71e25f6127038e2b9 upstream. The MT8183 AFE probe uses pm_runtime_get_sync() before reading hardware defaults into the regmap cache, but does not check whether runtime resume failed. If regmap_reinit_cache() then fails, the temporary runtime PM usage count is also not released. Use pm_runtime_resume_and_get() so resume failures abort probe without leaking a usage count, and release the temporary reference before handling the regmap cache result. Fixes: a94aec035a12 ("ASoC: mediatek: mt8183: add platform driver") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260527-asoc-mt8183-probe-cleanup-v1-2-4f4f5593c8d1@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4c9df23e121f1095f02cc7e1531ce3a6d74ff697 Author: Cássio Gabriel Date: Wed May 27 10:55:46 2026 -0300 ASoC: mediatek: mt8192: Release reserved memory on cleanup commit 965e17ae6751c5d3302430c8ebd650e72d45a85f upstream. The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind. Fixes: ec4a10ca4a68 ("ASoC: mediatek: use reserved memory or enable buffer pre-allocation") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260527-asoc-mt8192-probe-cleanup-v1-1-1bb834d05b72@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f6e424835cc05d215c57b6370b2c1e353dd02915 Author: Cássio Gabriel Date: Wed May 27 10:55:47 2026 -0300 ASoC: mediatek: mt8192: Check runtime resume during probe commit e24d5dde56a50946020b134fa8448869093db76a upstream. The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes. Fixes: 125ab5d588b0 ("ASoC: mediatek: mt8192: add platform driver") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260527-asoc-mt8192-probe-cleanup-v1-2-1bb834d05b72@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2a591bf6fd41fd14bdae689aafac4a9ee702c23c Author: Peter Ujfalusi Date: Tue Jun 9 11:34:56 2026 +0300 ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control commit 390aa4c9339bb0ec0bc8d554e830faf93ca9d49e upstream. In snd_sof_update_control(), firmware-provided cdata->num_elems is checked against local_cdata->data->size but never against the actual allocation size. If local_cdata->data->size was previously set to an inconsistent value, the memcpy could write past the allocated buffer. Add a bounds check to ensure num_elems fits within the available space in the ipc_control_data allocation before copying. Fixes: 10f461d79c2d ("ASoC: SOF: Add IPC3 topology control ops") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f4933e1d11b97b6a0951648b7c3e53850e1b33a9 Author: Peter Ujfalusi Date: Tue Jun 9 11:34:58 2026 +0300 ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get commit fd46668d538993218eea19c6925c868ac0f2630c upstream. The ipc_control_data buffer is allocated as kzalloc(max_size), where max_size covers the entire struct sof_ipc_ctrl_data including its flexible array payload. However, the bounds checks in bytes_ext_put and _bytes_ext_get compared user data lengths against max_size directly, ignoring that cdata->data sits at an offset of sizeof(struct sof_ipc_ctrl_data) bytes into the allocation. This allowed writing up to sizeof(struct sof_ipc_ctrl_data) bytes past the end of the heap buffer from unprivileged userspace via the ALSA TLV kcontrol interface, and similarly allowed over-reading adjacent heap data on the get path. Fix all bounds checks to subtract sizeof(*cdata) from max_size so they reflect the actual space available at the cdata->data offset. Also fix the error-path restore in bytes_ext_put which wrote to cdata->data instead of cdata, causing the same overflow. Fixes: 67ec2a091630 ("ASoC: SOF: Add bytes_ext control IPC ops for IPC3") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ed7787c43ecf4ae27a3e700cab53a1ed646c7f8 Author: Zhao Dongdong Date: Wed Jun 10 15:20:43 2026 +0800 ASoC: SOF: topology: fix memory leak in snd_sof_load_topology commit d46f9f23897261da53ffbeb89d48a13982ba7d28 upstream. When the topology filename contains "dummy" and tplg_cnt is 0, the function returns -EINVAL directly without freeing the tplg_files allocated by kcalloc() at line 2497. This leaks memory on every such topology load attempt. Fix this by setting ret = -EINVAL and jumping to the out: label, which already handles the kfree(tplg_files) cleanup. Fixes: 99c159279c6d ("ASoC: SOF: don't check the existence of dummy topology") Cc: stable@vger.kernel.org Signed-off-by: Zhao Dongdong Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/tencent_3EED6D778DC52C3703A2D1EE8119372E8E08@qq.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2efd9797331a559b93ab888f451838f87bd6dfa3 Author: Abdun Nihaal Date: Thu May 14 13:54:39 2026 +0530 fbdev: tridentfb: fix potential memory leak in trident_pci_probe() commit 7a35ec619d9af8ee128320975c1252b8ad65f1e8 upstream. In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist(). Fixes: 6a5e3bd0c8bc ("tridentfb: Add DDC support") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit ed3b3eb212441fb5f287dfd24ebafe11d634f009 Author: Abdun Nihaal Date: Thu May 14 13:54:36 2026 +0530 fbdev: nvidia: fix potential memory leak in nvidiafb_probe() commit 85f5e38c162bdf9dbbe197275d416402712f3707 upstream. In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 7b96ce9f8e47538c3c6eebbb217c94d696975cac Author: Abdun Nihaal Date: Thu May 14 13:54:42 2026 +0530 fbdev: vesafb: fix memory leak in vesafb_probe() commit b15d708995c01bbffe7dcd634a31959f6805bed3 upstream. Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") the string returned from fb_get_options() is expected to be freed by the caller. But the string is not freed in vesafb_probe(). Fix that by freeing the option string after setup. Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit dae8f6ddc35cb1673dba32d2fd8f1f85cd377adf Author: Abdun Nihaal Date: Thu May 14 13:54:34 2026 +0530 fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() commit 6fcca16a2b19c37f60693c56cbc0c923364ff3ef upstream. The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist() Fixes: 2ece5f43b041 ("fbdev: add the carmine FB driver") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 2fd16a94bea5e0c3e93791436cf8a800b175762a Author: Abdun Nihaal Date: Thu May 14 13:54:38 2026 +0530 fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() commit bb019d755366cc3e777a12d4bf457ff289837370 upstream. In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). Fixes: 215059d2421f ("tdfxfb: make use of DDC information about connected monitor") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit aa387a3e51808f580b51593e3c2f3d4703d91c1a Author: Abdun Nihaal Date: Thu May 14 13:54:40 2026 +0530 fbdev: uvesafb: fix potential memory leak in uvesafb_probe() commit 033e56fed09047ee63072e9f58789f40c1c7079d upstream. Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label. Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 56964e8039150a14462005458b25f19d6cad8f4a Author: Abdun Nihaal Date: Thu May 14 13:54:37 2026 +0530 fbdev: s3fb: fix potential memory leak in s3_pci_probe() commit 3b0ed04bc852887a9164e1bbf521652e8ef3eb92 upstream. In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist() Fixes: 86c0f043a737 ("s3fb: add DDC support") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 2ede8fa708235c81ab18de14077f1a458bec7e22 Author: Abdun Nihaal Date: Thu May 14 13:54:35 2026 +0530 fbdev: i740fb: fix potential memory leak in i740fb_probe() commit 5936063409af230a2c88b8700c47b89a19fd70b5 upstream. In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist(). Fixes: 5350c65f4f15 ("Resurrect Intel740 driver: i740fb") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 1b1b43342fbf11eaf2a8926b9ed4805579d772ac Author: Abdun Nihaal Date: Thu May 14 13:54:33 2026 +0530 fbdev: radeon: fix potential memory leak in radeonfb_pci_register() commit df8c1101c9a08859da612b5d0a08d55d475522c6 upstream. The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 5276e3f75ddb51f980a8903f4b39e73cf42415e5 Author: Abdun Nihaal Date: Thu May 14 13:54:41 2026 +0530 fbdev: efifb: fix memory leak in efifb_probe() commit 9b6eaf101656958397a6012bf43f6e2e42c9e5cb upstream. Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") the string returned from fb_get_options() is expected to be freed by the caller, but the string is not freed in efifb_probe(). Fix that by freeing the option string after setup. Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit f6a1ac55e6ca70777b6f0989860b924238bafb7e Author: Li RongQing Date: Thu May 14 21:02:02 2026 -0400 fbdev: sm712: Fix operator precedence in big_swap macro commit 5dbe5b65df0b0c0ec77492427c274b7b5011890e upstream. The big_swap(p) macro was intended to swap bytes within 16-bit halves of a 32-bit value. However, because the bitwise shift operators (<<, >>) have higher precedence than the bitwise AND operator (&), the original code failed to perform any shifting on the masked bits. For example, 'p & 0xff00ff00 >> 8' was evaluated as 'p & (0xff00ff00 >> 8)', effectively neutralizing the intended swap. Fix this by adding parentheses to ensure the bitwise AND is performed before the shift, correctly implementing the byte swap logic. Fixes: 1461d66728648 ("staging: sm7xxfb: merge sm712fb with fbdev") Cc: stable@vger.kernel.org Signed-off-by: Li RongQing Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 9a94b85531852eb86283eca36ab041782c6b3518 Author: Abdun Nihaal Date: Thu May 14 13:54:30 2026 +0530 fbdev: hecubafb: fix potential memory leak in hecubafb_probe() commit cbef2a305a8a72969b86f96b7c07b86edde61aff upstream. The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit e818c397548cde68d64c6abf8be0a5f3e3eef7d1 Author: Abdun Nihaal Date: Thu May 14 13:54:31 2026 +0530 fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() commit 9d18a4e4234fd3ee0d0eed8ccbbb50cb76b2232c upstream. The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit a889978ec44fe33edb3fb7140dcbbb8e6465c1cb Author: Abdun Nihaal Date: Thu May 14 13:54:32 2026 +0530 fbdev: metronomefb: fix potential memory leak in metronomefb_probe() commit 894632b862a39b3fe1cb5de06fbae86225ea64de upstream. The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit bc00e0e376ee3572f5d26c174473abef1e35decc Author: Oliver Upton Date: Thu Jun 18 16:42:05 2026 -0700 KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory commit 4bd7dbe0b2243e6aa735cae4d5e1ff988b30b2a6 upstream. When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory. Cc: stable@vger.kernel.org Fixes: 2a359e072596 ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260618234207.1063941-5-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 0a5dd8cf4d58ea28da132c2097cd1c525302ac48 Author: Oliver Upton Date: Thu Jun 18 16:42:04 2026 -0700 KVM: arm64: nv: Re-translate VNCR before injecting abort commit bb645aa0a4caeaf7f9cd32e9a948594d434c1a8f upstream. KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults. Cc: stable@vger.kernel.org Fixes: 2a359e072596 ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Reported-by: Sashiko Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260618234207.1063941-4-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 53804b6839573c9c6fff5f4cf075d6746267345e Author: Oliver Upton Date: Thu Jun 18 16:42:03 2026 -0700 KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN commit 9f3e83345a56280efffe235c65593c7e544c0fcc upstream. kvm_handle_vncr_abort() assumes that s1_walk_result conveys an abort when kvm_translate_vncr() returns -EFAULT. This is not always the case as it's possible to encounter 'late' failures on the output of S1 translation, e.g. a GFN outside of the memslots. Fix it by preparing an external abort before returning from kvm_translate_vncr(). Get rid of the BUG_ON() in the fault injection path while at it. Cc: stable@vger.kernel.org Fixes: 2a359e072596 ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260618234207.1063941-3-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit d35defbdfcb15296ebe28968ad7452c1a8c11cea Author: Oliver Upton Date: Thu Jun 18 16:42:02 2026 -0700 KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR commit 2684e02bac41c5220f6c1ab2bdcc957b71812977 upstream. KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN. Cc: stable@vger.kernel.org Fixes: 2a359e072596 ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Link: https://lore.kernel.org/kvm/20260608082603.16AEC1F00893@smtp.kernel.org/ Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260618234207.1063941-2-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit dd3b237eb7780d65eae296d3d3a70012b6e7a02f Author: Weiming Shi Date: Wed Jun 17 12:08:21 2026 +0800 KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops() commit ff1022c3de46753eb7eba2f6efd990569e66ff95 upstream. kvm_hyp_handle_mops() resets the single-step state machine as part of rewinding state for a MOPS exception by modifying vcpu_cpsr() and writing the result directly into hardware. In the case of nested virtualization, vcpu_cpsr() is a synthetic value such that the rest of KVM can deal with vEL2 cleanly. That means the value requires translation before being written into hardware, which is unfortunately missing from the MOPS handler. Fix it by directly modifying SPSR_EL2 and avoiding the synthetic state altogether, which will be resynchronized on the next 'full' exit back to KVM. Fixes: 2de451a329cf ("KVM: arm64: Add handler for MOPS exceptions") Reported-by: Zhong Wang Reported-by: Xuanqing Shi Link: https://lore.kernel.org/all/ajE4lHQevXNHpl1M@Air.local/ Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260617040820.2194831-2-bestswngs@gmail.com Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 29227821e2320ff6a174c91742b4ce221fe8d563 Author: Fuad Tabba Date: Mon Jun 15 14:11:16 2026 +0100 KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions commit e2cb1f4578625e71f461d5c1ce70984193389cbb upstream. kvm_inject_el2_exception() writes ESR_EL2 for synchronous exceptions but not for SError. enter_exception64() does not write ESR_ELx for any exception type, so the constructed syndrome is dropped. A guest L2 hypervisor taking a nested SError observes stale ESR_EL2. This affects both kvm_inject_nested_serror() and the EASE path in kvm_inject_nested_sea(). Write ESR_EL2 for except_type_serror, matching except_type_sync. Fixes: 77ee70a07357 ("KVM: arm64: nv: Honor SError exception routing / masking") Reported-by: sashiko Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260615131116.390977-1-tabba@google.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7deadbc5dab5b8e2316364603bc6281129c8461c Author: Oliver Upton Date: Sun Jun 14 22:13:24 2026 -0700 KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2 commit 9f1667098c6ae7ec81a9a56859cfdacb822aa0d0 upstream. It is entirely possible for a guest to write to the ZCR_EL2 sysreg alias while in a nested context, as it is expected if FEAT_NV2 is advertised to the L1 hypervisor. Get rid of the bogus WARN which, since the hyp vectors were installed at this point, has the effect of a hyp_panic... Cc: stable@vger.kernel.org Fixes: 0cfc85b8f5cf ("KVM: arm64: nv: Load guest FP state for ZCR_EL2 trap") Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260615051324.830045-1-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit a805ab1914ea02796c9ff1ebfdb0eaa850b51b26 Author: Oliver Upton Date: Wed Jul 1 16:16:19 2026 -0700 KVM: arm64: Ensure level is always initialized when relaxing perms commit 100baf0184896f859290a684f864b8200d8ac872 upstream. stage2_update_leaf_attrs() returns early before writing to @level if the table walker returned an error. At the same time, kvm_pgtable_stage2_relax_perms() uses the level as a TLBI TTL hint when the error was EAGAIN, indicating the vCPU raced with a table update and the TLB entry it hit is now stale. Fall back to an unknown TTL if none was provided by the walk. Cc: stable@vger.kernel.org Fixes: be097997a273 ("KVM: arm64: Always invalidate TLB for stage-2 permission faults") Signed-off-by: Oliver Upton Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260701231620.3300204-2-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 34d8d7242c52c174add6b413d56420aa60f8054c Author: Bradley Morgan Date: Sun Jun 21 21:31:55 2026 +0000 KVM: arm64: account pKVM reclaim against the VM mm commit d098bb75d14fde2f12155f1a95ec0168160867ce upstream. Protected guest faults charge long term pins to the VM's mm. Teardown can run later from file release, where current->mm may be unrelated. Drop the charge from kvm->mm instead. Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()") Signed-off-by: Bradley Morgan Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260621213155.6019-1-include@grrlz.net Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0cbae0e296d27ce4c4cce83e34d40c2bfd8133aa Author: Marc Zyngier Date: Sat Jun 27 11:51:05 2026 +0100 KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers commit 3a07249981629ace483ebbef81ef6b34c2d2afec upstream. kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers. Reported-by: Will Deacon Fixes: 8a39d00670f07 ("KVM: kvm_io_bus: Add kvm_io_bus_get_dev() call") Link: https://lore.kernel.org/all/20260626111344.802555-1-maz@kernel.org Cc: stable@vger.kernel.org Reviewed-by: Oliver Upton Link: https://patch.msgid.link/20260627105105.1005990-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 2c87a087c20632d68920272173b5d7c47f9bcf70 Author: Sean Christopherson Date: Tue Jul 14 09:03:06 2026 -0700 KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid guest state commit 2f2312c422fd2695da772cecb30c69994b795964 upstream. Put all vmcs12 pages if KVM synthesizes a nested VM-Exit due to invalid guest while emulating VMLAUNCH or VMRESUME. The invalid guest state path doesn't use nested_vmx_vmexit() as that API is intended to be used if and only if L2 is active, and the open coded equivalent neglects to put the vmcs12 pages. Failure to put the vmcs12 pages leaks any pinned pages (and/or mappings) if L1 retries VMLAUNCH/VMRESUME. Note, the !from_vmenter scenario doesn't suffer the same problem, as vmx_get_nested_state_pages() only gets/pins/maps the vmcs12 pages if L2 is active, i.e. if a "full" VM-Exit is guaranteed before KVM will retry getting vmcs12 pages. Fixes: 96c66e87deee ("KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page") Fixes: 3278e0492554 ("KVM/nVMX: Use kvm_vcpu_map when mapping the posted interrupt descriptor table") Fixes: fe1911aa443e ("KVM: nVMX: Use kvm_vcpu_map() to get/pin vmcs12's APIC-access page") Reported-by: Minh Nguyen Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d5560b6569cd05ba72c6b33427fbabc6ec46b8cf Author: leixiang Date: Mon Jun 22 15:51:01 2026 +0800 KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails commit ed446e8aa894883c08892cfee69782fdf8f6c3ca upstream. Nullify irqfd->producer if updating the IRTE for bypass fails, as leaving a dangling pointer will result in a use-after-free if the irqfd is reachable through KVM's routing, but the producer is freed separately. E.g. for VFIO PCI, the producer is embedded in struct "vfio_pci_irq_ctx" and freed when the vector is disabled, which can happen independent of routing updates. Fixes: 77e1b8332d1d ("KVM: x86: Decouple device assignment from IRQ bypass") Cc: stable@vger.kernel.org Signed-off-by: leixiang Link: https://patch.msgid.link/1782119051448443.14545.seg@mailgw.kylinos.cn [sean: drop PPC change, massage changelog] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 32bdca80aa81c2cb906f50a88b220ce1ecdc5e6e Author: Sean Christopherson Date: Wed Jun 24 15:05:16 2026 -0700 KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs commit 9285e4070df2c40585c3d7ec9571faa7a2b97e17 upstream. Ignore KVM's internal "service pending PV EOI" request if the vCPU has disabled PV EOIs since the request was made. Asserting that PV EOIs are enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e. if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables PV EOIs. kernel BUG at arch/x86/kvm/lapic.c:3338! Oops: invalid opcode: 0000 [#1] SMP CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0xb40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- Fixes: ae7a2a3fb6f8 ("KVM: host side for eoi optimization") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260624220516.3033391-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d6b5aba65e99531c97b146622a406c75653819d5 Author: Binbin Wu Date: Fri Jul 10 11:53:23 2026 +0800 KVM: TDX: Reject concurrent change to CPUID entry count commit cfbebb55e5127dc162e73fa8956000055a78606c upstream. Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the initial read and the subsequent copy of the initialization data. tdx_td_init() first reads user_data->cpuid.nent to size the flexible kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent, and that field can differ from the value used to size the allocation if userspace modifies the input concurrently. setup_tdparams_cpuids() later passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as the array bound for the copied entries. Require the copied count to match the value used to size the allocation so that CPUID parsing cannot access beyond the entries actually copied. Fixes: 0bd0a4a1428b ("KVM: TDX: Replace kmalloc + copy_from_user with memdup_user in tdx_td_init()") Reported-by: Sashiko:gemini-3.1-pro-preview Cc: Signed-off-by: Binbin Wu Reviewed-by: Xiaoyao Li Reviewed-by: Thorsten Blum Link: https://patch.msgid.link/20260710035324.3170534-1-binbin.wu@linux.intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d2f9df3b615ca0cd45899c090366945528186052 Author: Atish Patra Date: Tue Jun 2 15:36:32 2026 -0700 KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs commit 6ee4140788234a6fabf59e6a50e38cdb936008cd upstream. The intra-host migration/mirroring feature is not fully implemented for SEV-SNP VMs. The proper migration requires additional SNP-specific state such as guest_req_mutex, guest_req_buf, and guest_resp_buf to be transferred or initialized on the destination. The SNP VM mirroring requires vmsa features to be copied as well otherwise ASID would be bound to SNP range while VM is detected as a SEV VM. Reject SNP source VMs in migration/mirroring until proper SNP state transfer is implemented. Fixes: 1dfe571c12cf ("KVM: SEV: Add initial SEV-SNP support") Reported-by: Chris Mason Reported-by: Sashiko Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Tom Lendacky Signed-off-by: Atish Patra Link: https://patch.msgid.link/20260602-sev_snp_fixes-v3-1-24bfd3ae047c@meta.com Cc: stable@vger.kernel.org [sean: let lines poke past 80 chars, tag for stable] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 124a3769c43713a11a93a821b313e61ad5110cb8 Author: Matthew Rosato Date: Thu Jul 9 09:54:04 2026 -0400 KVM: s390: pci: Fix handling of AIF enable without AISB commit 3e3aa6da87d30a0064a17b836685cd43c90a3572 upstream. When a guest seeks to register IRQs without a summary bit specified, ensure that the associated GAITE then stores 0 for the guest AISB location instead of virt_to_phys(page_address(NULL)). Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Farhan Ali Signed-off-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 7d066368f72e6192af7e21c5817626f6da666991 Author: Sean Christopherson Date: Fri Jun 12 07:56:41 2026 -0700 KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks commit ebdac7554abb347ca4197be241116842161acd9b upstream. Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a "late" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD. Fixes: 1100e4910ad2 ("KVM: nVMX: Add an off-by-default module param to WARN on missed consistency checks") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260612145642.452392-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit b1a89d12d35a8256d2b170ced0b1c86851f3def2 Author: Marc Zyngier Date: Mon Jun 15 19:16:25 2026 +0100 KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling commit 7258770e5814f15e8308ebda82ac9acf6964ba8e upstream. Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story). Reported-by: Hyunwoo Kim Tested-by: Hyunwoo Kim Link: https://lore.kernel.org/r/ailsCnyoS82r_QRz@v4bel Link: https://patch.msgid.link/20260615181625.3029352-1-maz@kernel.org Fixes: 5dd4b924e390a ("KVM: arm/arm64: vgic: Add refcounting for IRQs") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0658b09cba7fe866c6cd70cd2dcdfdcabe80328f Author: Hyunwoo Kim Date: Fri Jun 5 05:59:15 2026 +0900 KVM: arm64: vgic: Check the interrupt is still ours before migrating it commit 0074b82cdfcb5fd13710a0ac308ade68ac6f6fbe upstream. vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it. Fixes: 0919e84c0fc1 ("KVM: arm/arm64: vgic-new: Add IRQ sync/flush framework") Signed-off-by: Hyunwoo Kim Link: https://patch.msgid.link/aiHnI1mu6SGQrgnz@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit adce12bb0e0dc82d1d6f0821c9faee3145e62a6f Author: Haoxiang Li Date: Wed Jun 24 14:19:10 2026 +0800 KVM: s390: pci: Fix GISC refcount leak on AIF enable failure commit 7b69729046a4c58f4cb457184e5ac4aaa179bff4 upstream. kvm_s390_gisc_register() registers the guest ISC before pinning the guest interrupt forwarding pages and allocating the AISB bit. If any of the later setup steps fails, the function unwinds the pinned pages and other local state, but does not unregister the GISC reference. Add the missing kvm_s390_gisc_unregister() to the error unwind path. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Acked-by: Claudio Imbrenda Reviewed-by: Christian Borntraeger Signed-off-by: Claudio Imbrenda Message-ID: <20260624061910.2794734-1-haoxiang_li2024@163.com> Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit a2e7bbc91cf621a033a37800b86366f35b0e4303 Author: Gautam Menghani Date: Mon Jun 15 14:41:19 2026 +0530 powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM commit fe179677b6dcb4b658586038a811f87265e97777 upstream. Currently, CONFIG_VPA_PMU is not enabled by default, and consequently cannot be used for KVM guests at all, unless explicitly enabled on host kernel. Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is being used. Cc: stable@vger.kernel.org # v6.13+ Suggested-by: Sean Christopherson Reviewed-by: Amit Machhiwal Reviewed-by: Harsh Prateek Bora Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Gautam Menghani [Maddy: Changed tag order] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260615091120.84169-1-gautam@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit ce587046baacdeb774b7756ab29b3f594e429004 Author: Claudio Imbrenda Date: Thu Jun 11 12:48:47 2026 +0200 KVM: s390: Fix unlikely race in try_get_locked_pte() commit 5670b7f927f8d98685f3f5873dbf9f8d7a5a63f3 upstream. Fix an unlikely race in try_get_locked_pte(), which could have happened if puds or pmds get unmapped between the p?dp_get() and p?d_offset() functions. Fixes: 89fa757931dc ("KVM: s390: Avoid potentially sleeping while atomic when zapping pages") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda Message-ID: <20260611104850.110313-3-imbrenda@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit a4a19941ccb2164edc3491faa5ac5df82e94b363 Author: Christian Borntraeger Date: Thu Jun 11 12:50:36 2026 +0200 KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory commit c7dda3d0f869dc97223448a06c9a2e5235928e48 upstream. kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(), which does not zero the returned pages: values = vmalloc(args->count); In the non-peek (migration) path, dat_get_cmma() reports a byte count spanning from the first to the last dirty page, but __dat_get_cmma_pte() writes values[gfn - start] only for pages whose CMMA dirty bit is set. The walk uses DAT_WALK_IGN_HOLES, so clean and unmapped pages that lie between two dirty pages within the reported span are visited but never store their byte. Those gaps (up to KVM_S390_MAX_BIT_DISTANCE pages each) stay uninitialized yet fall inside [0, count) and are copied out by copy_to_user(), disclosing stale kernel memory to user space. Before the switch to the new gmap implementation the buffer was fully populated for every gfn in the span, so no uninitialized bytes were exposed; the dirty-only walk introduced the leak. Use vzalloc() so the gaps read back as zero. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260611105036.11491-1-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 5fc9690db3bf8c372efb6a31f9a0da48e7189750 Author: Claudio Imbrenda Date: Thu Jun 11 12:48:50 2026 +0200 KVM: s390: vsie: Use mmu cache to allocate rmap commit abeb7eb57f1671d9185ddf11236c784f07bdb928 upstream. Use kvm_s390_mmu_cache_alloc_rmap() to allocate the rmap in gmap_insert_rmap(), instead of a normal kzalloc_obj() with GFP_ATOMIC. This guarantees forward progress. Fixes: a2c17f9270cc ("KVM: s390: New gmap code") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda Message-ID: <20260611104850.110313-6-imbrenda@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit eeeb9bc718311b5478b8caae840b94348e89ad09 Author: Claudio Imbrenda Date: Thu Jun 11 12:48:46 2026 +0200 KVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic() commit f79413b2dde10829a1b526543e725dd5c1847e9a upstream. While dat_crstep_xchg_atomic() is marked as __must_check, in this particular case the return value should be ignored. Silence potential compiler warnings with a pointless check, and add a comment to explain the situation. Fixes: d1adc098ce08 ("KVM: s390: Fix _gmap_crstep_xchg_atomic()") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda Message-ID: <20260611104850.110313-2-imbrenda@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 0c3d4ca328e661cb4eda3bb344ea17e4b6a63171 Author: Claudio Imbrenda Date: Thu Jun 11 12:48:49 2026 +0200 KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault() commit 668e70cc545e2659f3c4adad20a0883533042473 upstream. Add missing radix_tree_preload() in _gaccess_shadow_fault() to guarantee forward progress. The core of _gaccess_shadow_fault() has been split into ___gaccess_shadow_fault() in order to simplify locking. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda Message-ID: <20260611104850.110313-5-imbrenda@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit bcc6b684fcf6366fe08f61d841b924c0cb36d491 Author: Claudio Imbrenda Date: Thu Jun 11 12:48:48 2026 +0200 KVM: s390: vsie: Fix allocation of struct vsie_rmap commit 505fcce0c64957f475f9b11fb1403821b7f33e7e upstream. The allocation size for struct vsie_rmap in kvm_s390_mmu_cache_topup() was wrong due to a copy-paste error. Fix it by using the type name. Fixes: 12f2f61a9e1a ("KVM: s390: KVM page table management functions: allocation") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda Message-ID: <20260611104850.110313-4-imbrenda@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit ac33662452217f6ea66c30dc129c70b3148ba459 Author: Qiang Ma Date: Thu Jun 11 20:46:43 2026 +0800 LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr() commit ebd50de14f1a06b7e0206083904bcc62b9ba65be upstream. The LoongArch CSRXCHG instruction returns the full old CSR value in rd after applying the masked update. kvm_emu_xchg_csr() currently masks the saved value before returning it to the guest, so rd receives only the bits selected by the write mask. That breaks the architectural behavior and makes a zero mask return 0 instead of the previous CSR value. So, keep the masked CSR update, but return the unmodified old CSR value. Cc: stable@vger.kernel.org Fixes: da50f5a693ff ("LoongArch: KVM: Implement handle csr exception") Reviewed-by: Bibo Mao Signed-off-by: Qiang Ma Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 31e99851ee9973670d4a2cda8a056851e23895cf Author: Bibo Mao Date: Thu Jun 11 20:46:40 2026 +0800 LoongArch: KVM: Fix FPU register width with user access API commit f4caaac76379daf4a617d9134b6087fb2636fb31 upstream. At the beginning, only 64 bit FPU is supported. With FPU register get interface, 64 bit FPU data is copied to user space, the same with FPU register set API. However with LSX and LASX supported in later, there should be FPU data copied with bigger width. So here fixes this issue, copy the whole 256 bit FPU data from/to user space. Cc: stable@vger.kernel.org Fixes: db1ecca22edf ("LoongArch: KVM: Add LSX (128bit SIMD) support") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 5c827b66a626b41ad9a4cdff1c12fc287c38ba87 Author: Qiang Ma Date: Thu Jun 11 20:46:43 2026 +0800 LoongArch: KVM: Check the return values for put_user() commit fb89e0fe2dc4246c86ad0eb0fa2b7cb2f8ba9728 upstream. put_user() may return -EFAULT, so, when the user space address is invalid, the caller should return -EFAULT. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Qiang Ma Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d4574547e04a47ad498149576f65b84475ea6f4c Author: Bibo Mao Date: Thu Jun 11 20:46:40 2026 +0800 LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt() commit 09b318ab77b7a4fc9987fd98d1525fc55ddc2617 upstream. Function kvm_vcpu_ioctl_interrupt() can be called from userspace, here add irq validility cheking in kvm_vcpu_ioctl_interrupt(). Cc: stable@vger.kernel.org Fixes: f45ad5b8aa93 ("LoongArch: KVM: Implement vcpu interrupt operations") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 8b3e188d19e4ffe916780aeb7ddad9d6457b8bcc Author: Yanfei Xu Date: Thu Jun 11 20:46:43 2026 +0800 LoongArch: KVM: Validate irqchip index in irqfd routing commit 3474037904c20ff915e3ebab0ab5c1e41bbe549e upstream. Sashiko reported that the irqchip index is not validated for LoongArch. Add validation and reject out-of-range irqchip indexes to avoid indexing past the routing table's chip array. Cc: stable@vger.kernel.org Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support") Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/ Reported-by: Sashiko Reviewed-by: Bibo Mao Signed-off-by: Yanfei Xu Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 81f5b85a5fb0ae20b84a89b05852375123a11def Author: David Jander Date: Wed Mar 18 11:51:23 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to board files commit a0d6c2a06fffff47bcca4d5bfdab4cc428a315fc upstream. Move the gpio-line-names properties for the I2C GPIO expanders (gpio0 and gpio1) out of the common mecio1-io.dtsi file and into the specific board dts files. The layout originally defined in the common include file belonged to the mecio1r1 (Revision 1) hardware. This layout is moved 1:1 into the stm32mp153c-mecio1r1.dts file. The mecio1r0 (Revision 0) hardware utilizes a completely different pinout for these expanders. A new, accurate mapping reflecting the Revision 0 schematics is added to stm32mp151c-mecio1r0.dts. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260318105123.819807-8-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit 7b5e3c15eee1d5bf42cd4cee3fa93415f4ae148e Author: David Jander Date: Wed Mar 18 11:51:22 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo commit dfb93c4acce8ad9c4f573128b2cf7ddb936e0de7 upstream. Fix a copy-paste error in the GPIO line names for the TCA6416 expander (gpio@20). The common mecio1-io include file was originally defined using the mecio1r1 (Revision 1) hardware layout, but incorrectly labeled pin 13 as "HSIN9_BIAS" instead of the actual "HSIN7_BIAS" present in the schematics. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260318105123.819807-7-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit d735c64a1462d0a270b67ad95f136b529eec94ab Author: David Jander Date: Wed Mar 18 11:51:21 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board files commit 4f5069609ac99894c0632d8b8c4c016f85199de9 upstream. Move the gpio-line-names properties out of the common mecio1-io.dtsi file and into the specific board dts files. The pinout originally defined in the common include file belonged to the mecio1r0 (Revision 0) hardware. This is moved 1:1 into the stm32mp151c-mecio1r0.dts file without any modifications. A large number of GPIO pins are swapped on the mecio1r1 (Revision 1) hardware, so a new, board-specific gpio-line-names mapping is added to stm32mp153c-mecio1r1.dts to reflect those hardware changes. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: Link: https://lore.kernel.org/r/20260318105123.819807-6-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit e61543c0aa5a9d3904374fd4c718ae6919ddc86d Author: Abel Vesa Date: Mon Mar 23 12:01:12 2026 +0200 arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers commit c17e220946675232d383620ed9cff6685735ec48 upstream. According to internal documentation, the corners specific for each rate from the DP link clock are: - LOWSVS_D1 -> 19.2 MHz - LOWSVS -> 270 MHz - SVS -> 540 MHz (594 MHz in case of DP3) - SVS_L1 -> 594 MHz - NOM -> 810 MHz - NOM_L1 -> 810 MHz - TURBO -> 810 MHz So fix all tables for each of the four controllers according to the documentation, but since DP0 through DP2 have the same entries in their tables, lets drop the DP1 and DP2 and have all of them share the DP0 table instead. However keep a separate table for the DP3 as it is different for the SVS, compared to the rest of the controllers. The 19.2 MHz @ LOWSVS_D1 isn't needed as it's not an actual working frequency and the controller will never select it. So remove it. Cc: stable@vger.kernel.org # v6.9+ Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Suggested-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260323-hamoa-fix-dp3-opp-table-v3-1-a823776bd1b0@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit fc58177cca3bce9c77ee3784da65786cb023226c Author: David Jander Date: Wed Mar 18 11:51:20 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo commit b04ccecb714de913e360f0866c66f38e1606e89b upstream. The reset pins for the LPOUT lines were incorrectly prefixed with "GPOUT" instead of "LPOUT" in the gpio-line-names array. Fix these typos so the pin names consistently match the LPOUT0-4 signals they belong to. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: Link: https://lore.kernel.org/r/20260318105123.819807-5-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit 73e14c8bf53cb853480421b8f6a153395cbae1df Author: Krzysztof Kozlowski Date: Mon Apr 13 11:07:24 2026 +0200 arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags commit b4f5c46163b3fe3ec7ed8a76dff8b7e80a776a1f upstream. IRQ_TYPE_xxx flags are not correct in the context of GPIO flags. These are simple defines so they could be used in DTS but they will not have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED. Correct the Type-C int-gpios to use proper flags, assuming the author of the code wanted similar logical behavior: IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW Fixes: c4b4593ecb0b ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman commit 520de5e79ddadaded3cd0a04c6cb19161f0e5259 Author: David Jander Date: Wed Mar 18 11:51:17 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference commit c84f22405085d91cd5f0c5b967318371c07904ba upstream. Switch the ADC reference supply from the general 3.3V rail to the internal 2.5V VREFBUF regulator. The ADC circuits on this board are designed for the internal 2.5V reference. Without this change, all ADC measurement values are incorrect. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: Link: https://lore.kernel.org/r/20260318105123.819807-2-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit 0623e082e99ab1e7eba999255a183476180fe4c1 Author: Judith Mendez Date: Tue Mar 24 09:02:47 2026 -0500 arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc commit d8fe8442366ffd8306575028bda92389d0dfb674 upstream. Add bootph-all property to vqmmc voltage regulator node and its corresponding pinmux node to make it available during all boot phases. This allows to run tuning early in SPL stages of boot. Fixes: 8f023012eb4a ("arm64: dts: ti: k3-am62a: Enable UHS mode support for SD cards") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Link: https://patch.msgid.link/20260324140247.1200631-1-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Greg Kroah-Hartman commit ba13b141ddb58cc1eaefff856d767334f3dfc47c Author: David Jander Date: Wed Mar 18 11:51:19 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC channels to board files commit 70f1d8fcbd121a40f51b6c846d41e8cbb38ba210 upstream. Move the divergent adc1 channel definitions out of the common mecio1-io.dtsi file and into the specific Revision 0 and Revision 1 board files. The original common file contained incorrect schematic labels for the Revision 0 hardware (e.g., labeling ana0 as p24v_hpdcm instead of ain_aux0) and failed to account for physical signal routing changes between the board revisions. Retain only the strictly shared channels in the common include file. Map the correct channels and schematic labels directly within stm32mp151c-mecio1r0.dts and stm32mp153c-mecio1r1.dts. Crucially, ensure that the required 200us sample time follows the phint1_ain signal to its new physical location on channel 3 for the Revision 1 hardware. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: Link: https://lore.kernel.org/r/20260318105123.819807-4-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit d09c701a531c198809f35a4fdf23749d9e686835 Author: David Jander Date: Wed Mar 18 11:51:18 2026 +0100 ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times commit 8407e611faf80ce790a393addf7b44cc595742af upstream. Increase the minimum ADC sample times for all configured channels on ADC1 and ADC2 to ensure measurement accuracy meets specifications. The default 5us sample time is insufficient for the internal sampling capacitor to fully charge. Increase the default time to 20us to relax the input impedance requirements. Additionally, the phint0_ain and phint1_ain channels require a much longer sampling period due to their specific circuit design. Increase their sample times to 200us. Remove stale comments regarding clock cycles that no longer match the updated timings. Fixes: 8267753c891c ("ARM: dts: stm32: Add MECIO1 and MECT1S board variants") Co-developed-by: Oleksij Rempel Signed-off-by: David Jander Signed-off-by: Oleksij Rempel Cc: Link: https://lore.kernel.org/r/20260318105123.819807-3-o.rempel@pengutronix.de Signed-off-by: Alexandre Torgue Signed-off-by: Greg Kroah-Hartman commit 12cabe872172ed3a295351878b6abc34931c32a8 Author: Quentin Schulz Date: Tue Apr 21 11:45:06 2026 +0200 arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck commit ae653cb854f36d1555681ce70ca3d80d0ec73516 upstream. When not passing the PHY ID with an ethernet-phy-idX.Y compatible property, the MDIO bus will attempt to auto-detect the PHY by reading its registers and then probing the appropriate driver. For this to work, the PHY needs to be in a working state. Unfortunately, the net subsystem doesn't control the PHY reset GPIO when attempting to auto-detect the PHY. This means the PHY needs to be in a working state when entering the Linux kernel. This historically has been the case for this device, but only because the bootloader was taking care of initializing the Ethernet controller even when not using it. We're attempting to support the removal of the network stack in the bootloader, which means the Linux kernel will be entered with the PHY still in reset and now Ethernet doesn't work anymore. The devices in the field only ever had a TI DP83825, so let's simply bypass the auto-detection mechanism entirely by passing the appropriate PHY IDs via the compatible. Note that this is only an issue since commit e463625af7f9 ("arm64: dts: rockchip: move reset to dedicated eth-phy node on ringneck") as before that commit the reset was done by the MAC controller before starting the MDIO auto-detection mechanism, via the snps,reset-* properties. Cc: stable@vger.kernel.org Fixes: e463625af7f9 ("arm64: dts: rockchip: move reset to dedicated eth-phy node on ringneck") Signed-off-by: Quentin Schulz Link: https://patch.msgid.link/20260421-px30-eth-phy-v2-2-68c375b120fd@cherry.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit b5ab9ada87e83a36f036e1bb7d791c9736f28ef0 Author: Nickolay Goppen Date: Wed Apr 29 12:30:11 2026 +0300 arm64: dts: qcom: sdm630: describe adsp_mem region properly commit ce414263e9ebe5080381a50cbdf9065c29816202 upstream. Downstream [1] this region is marked as shared, reusable and dynamic so describe it that way. [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448 Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Cc: stable@vger.kernel.org Reviewed-by: Ekansh Gupta Reviewed-by: Dmitry Baryshkov Signed-off-by: Nickolay Goppen Link: https://lore.kernel.org/r/20260429-qcom-sdm660-cdsp-adsp-fastrpc-dts-fix-v5-4-16bc82e622ad@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 17b7ab1d26b3e52567eca2c45f829a1769d8b4bd Author: Hugo Villeneuve Date: Thu Mar 5 13:06:16 2026 -0500 ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply property commit 0372cc5776e7fd5570884aed0c1e9a8a546cad66 upstream. The dc-supply property is non-existent in Linux now, nor when this DTS file was created when importing it from Variscite own kernel. Therefore remove it to fix this warning: imx6ul-var-som-concerto.dtb: cpu@0 (arm,cortex-a7): Unevaluated properties are not allowed ('dc-supply' was unexpected) from schema $id: http://devicetree.org/schemas/arm/cpus.yaml Fixes: 9d6a67d9c7a9 ("ARM: dts: imx6ul: Add Variscite VAR-SOM-MX6UL SoM support") Cc: stable@kernel.org Signed-off-by: Hugo Villeneuve Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman commit 7cc51bb053f6b4bb17db4e10afcef3147566cb47 Author: Marek Vasut Date: Fri Jul 10 18:04:22 2026 +0200 arm64: dts: renesas: ironhide: Describe inline ECC carveouts commit 6fa6ee724d8dadf392139e242ac936b5da730c4b upstream. The DBSC5 DRAM controller protects DRAM content using inline ECC. The inline ECC utilizes areas of DRAM for its operation, which are in the DRAM address range, but must not be accessed or modified. Describe the inline ECC carveout areas used by the DBSC5 controller on this hardware as reserved-memory, which must not be accessed. Include DRAM areas which are unprotected by ECC as well, those are parts of the DRAM which directly precede the ECC carveout. In case of high DRAM utilization, unless the inline ECC carveouts are properly reserved, Linux may use and corrupt the memory used by the DBSC5 DRAM controller for inline ECC, which would lead to the system becoming unstable. Fixes: ad142a4ef710 ("arm64: dts: renesas: r8a78000: Add initial Ironhide board support") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Tested-by: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260710160450.64967-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 7b71b69719eb164c58172258f126f7d272ac81a8 Author: Krzysztof Kozlowski Date: Thu May 28 14:03:24 2026 +0200 arm64: dts: s32g3: Fix SWT8 watchdog address commit 65210e81f7837a871a17237d15e4b1191d5e8771 upstream. Add missing hex annotation to fix the SWT8 watchdog address in 'reg' property, as reported by dtc W=1: s32g3.dtsi:863.27-869.5: Warning (simple_bus_reg): /soc@0/watchdog@40500000: simple-bus unit address format error, expected "269fb20" Lack of hex '0x' meant address would be interpreted as decimal thus completely different value used as this device MMIO. If device was enabled this could lead to corruption of other device address space and broken boot. Cc: stable@vger.kernel.org Fixes: 6db84f042745 ("arm64: dts: s32g3: Add the Software Timer Watchdog (SWT) nodes") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Lezcano Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman commit 9b6a94b187f4d5e97c1e8f7c8648964e43d9ee86 Author: Mark Rutland Date: Wed Jun 3 12:06:11 2026 +0100 arm64: fpsimd: Fix type mismatch in sve_{save,load}_state() commit ae24f6b06e90681ec36b9c21c3f5c09618350f5a upstream. The sve_save_state() and sve_load_state() functions take a 32-bit int argument that describes whether to save/restore the FFR. Their assembly implementations consume the entire 64-bit register containing this 32-bit value, and will attempt to save/restore the FFR if any bit of that 64-bit register is non-zero. Per the AAPCS64 parameter passing rules, the callee is responsible for any necessary widening, and the upper 32-bits are permitted to contain arbitrary values. If the upper 32 bits are non-zero, this could result in an unexpected attempt to save/restore the FFR, and consequently could lead to unexpected traps/undefs/faults. In practice compilers are very unlikely to generate code where the upper 32-bits would be non-zero, but they are permitted to do so. Fix this by only consuming the low 32 bits of the register, and update comments accordingly. The hyp code __sve_save_state() and __sve_restore_state() functions don't have the same latent bug as they override the full 64-bit register containing the argument. Fixes: 9f5848665788 ("arm64/sve: Make access to FFR optional") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Fuad Tabba Cc: James Morse Cc: Marc Zyngier Cc: Mark Brown Cc: Oliver Upton Cc: Vladimir Murzin Cc: Will Deacon Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit b69ad768cd4a2ef4e07c18492ae85438ed17c7cb Author: Yong Wang Date: Thu Jun 11 02:37:43 2026 +0800 net: ife: require ETH_HLEN to be pullable in ife_decode() commit 9406f6012b7343661efb516a11c62d4db2b62f75 upstream. ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning. Fixes: ef6980b6becb ("introduce IFE action") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Signed-off-by: Yong Wang Signed-off-by: Ren Wei Link: https://patch.msgid.link/20260610183814.1648888-2-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 463d417a905dfc671d8a1b59e1f45780384334ea Author: Runyu Xiao Date: Fri Jun 12 00:00:14 2026 +0800 octeontx2-vf: clear stale mailbox IRQ state before request_irq() commit 0b352f04b9be2c83c0240aa6dae7257fefa90464 upstream. otx2vf_register_mbox_intr() currently installs the VF mailbox IRQ handler before clearing stale mailbox interrupt state. The code then says that local interrupt bits should be cleared first to avoid spurious interrupts, but that clear still happens only after request_irq() has already made the handler reachable. A running system can reach this during VF mailbox interrupt registration while stale or latched RVU_VF_INT state is still present. If delivery happens in the request_irq()-to-clear window, otx2vf_vfaf_mbox_intr_handler() can run before local quiesce and touch the same vf->mbox and vf->mbox_wq carrier that probe and teardown later reuse or destroy. Move the stale mailbox interrupt clear ahead of request_irq(), but keep interrupt enabling after the handler is installed. This closes the pre-clear early-IRQ window without creating a new enable-before-handler window. Fixes: 3184fb5ba96e ("octeontx2-vf: Virtual function driver support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Simon Horman Reviewed-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260611160014.3202224-3-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1ffc164c474473a162a0c20e21673823324a035f Author: Runyu Xiao Date: Fri Jun 12 00:00:13 2026 +0800 octeontx2-pf: clear stale mailbox IRQ state before request_irq() commit f918554fb7246e89b98ef90abe80801f038258b3 upstream. otx2_register_mbox_intr() currently installs the PF mailbox IRQ handler before clearing stale mailbox interrupt state. The function itself then comments that the local interrupt bits must be cleared first to avoid spurious interrupts, but that clear happens only after request_irq() has already exposed the handler to irq delivery. A running system can reach this during PF mailbox interrupt registration while stale or latched RVU_PF_INT state is still present. If delivery happens in the request_irq()-to-clear window, otx2_pfaf_mbox_intr_handler() can run before local quiesce and touch the same pf->mbox and pf->mbox_wq carrier that probe and teardown later reuse or destroy. Move the stale mailbox interrupt clear ahead of request_irq(), but keep interrupt enabling after the handler is installed. This closes the pre-clear early-IRQ window without creating a new enable-before-handler window. Fixes: 5a6d7c9daef3 ("octeontx2-pf: Mailbox communication with AF") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Simon Horman Reviewed-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260611160014.3202224-2-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 806b7b6edc8446e8b94b706807a7090a14d47b5c Author: Zhengchuan Liang Date: Tue Jun 9 16:34:37 2026 +0800 net: atm: reject out-of-range traffic classes in QoS validation commit cdf19f380e46192e7084be559638aab1f6ed86a2 upstream. Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/58f02c6f73d9818fd5d2022e1116759fdde6116b.1780965530.git.zcliangcn@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7f72c285f6d3bf63968a0344beee8ab1b370198b Author: Michael Bommarito Date: Thu Jun 11 08:54:55 2026 -0400 net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() commit 20054869770c7df060c5ecee3e8bbf9029c47191 upstream. qrtr_endpoint_post() validates an incoming packet with if (!size || len != ALIGN(size, 4) + hdrlen) goto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN. Fixes: ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260611125455.2352279-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6acbbe54215d5f4251593000cff2bf51d6748713 Author: Li Xiasong Date: Thu Jun 11 21:56:47 2026 +0800 tipc: restrict socket queue dumps in enqueue tracepoints commit acd7df8d955480a6f6e5bb809da67b1500cc3cf4 upstream. tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context. Fixes: 01e661ebfbad ("tipc: add trace_events for tipc socket") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260611135647.3666727-1-lixiasong1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 201b60c4d15538fcc3c0c2ea9b75dd7d0f58022c Author: Cássio Gabriel Date: Wed Jun 3 14:57:54 2026 -0300 ASoC: SOF: topology: validate vendor array size before parsing commit 8468dd79cfb2ffbdeaf7c353f63d64941cb8ba05 upstream. sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below. Cast sizeof(*array) to int when validating the declared array size. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code. Link: https://lore.kernel.org/stable/CANiDSCsjR5NHqu_Ui5cOqWdJgFqmYsQ9WR8O7m0WOhngaYXFpw@mail.gmail.com/t/#m9b3be379221e79327cc13fd71009287368ef4f23 Fixes: 215e5fe75881 ("ASoC: SOF: topology: reject invalid vendor array size in token parser") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260603-sof-topology-array-size-signed-v1-1-84f97879a4ef@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 92f90917413bdd6078fefff6f6c83a07bf870b04 Author: Peter Ujfalusi Date: Tue Jun 9 11:34:57 2026 +0300 ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get commit 1f97760417b5faa60e9642fd0ed61eb17d0b1b39 upstream. In sof_ipc3_bytes_put(), the size used for the memcpy is derived from the old data->size already in the buffer, not the incoming new data's size field. If the new data has a different size, the copy length is wrong: it may truncate valid data or copy stale bytes. Similarly, sof_ipc3_bytes_get() checks data->size against max_size without accounting for the sizeof(struct sof_ipc_ctrl_data) offset of the flex array within the allocation. Fix bytes_put to validate and use the incoming data's sof_abi_hdr.size from ucontrol before copying. Fix bytes_get to subtract sizeof(*cdata) from the bounds check to match the actual available space. Fixes: 544ac8858f24 ("ASoC: SOF: Add bytes_get/put control IPC ops for IPC3") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 312c7d2ebe696da3f885eee77d52297664e57c53 Author: Peter Ujfalusi Date: Tue Jun 9 11:34:55 2026 +0300 ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc commit 8791977d7289f6e9d2b014f60a5455f053a7bc04 upstream. In sof_ipc3_control_update(), the expected_size calculation uses firmware-provided cdata->num_elems in arithmetic that could overflow on 32-bit platforms, wrapping to a small value. This would allow the cdata->rhdr.hdr.size comparison to pass with mismatched sizes, potentially leading to out-of-bounds access in snd_sof_update_control. Use check_mul_overflow() and check_add_overflow() to detect and reject overflowed size calculations. Fixes: 10f461d79c2d ("ASoC: SOF: Add IPC3 topology control ops") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c29f5b4498894aebb2f87b1a29bb320e2f9348f9 Author: Peter Ujfalusi Date: Tue Jun 9 11:34:54 2026 +0300 ASoC: SOF: ipc4-control: Validate notification payload size commit 5bdfeccb7fbf6e000fc783cd8412732e67c1ad0c upstream. Validate MODULE_NOTIFICATION payload length before reading bytes/channel data in control update handling. Fixes: 2a28b5240f2b ("ASoC: SOF: ipc4-control: Add support for generic bytes control") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 038406abde0d0883419ec89425ea941ec8bbef95 Author: Peter Ujfalusi Date: Tue Jun 9 11:34:53 2026 +0300 ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put commit 3ad673e7139cf214afd24321a829aad6575f4163 upstream. In sof_ipc4_bytes_put(), the copy size is derived from the old data->size in the buffer rather than the incoming new data's size field from ucontrol. If the new data has a different size, the copy uses the wrong length: it may truncate valid data or copy stale bytes. Fix by validating and using the incoming data's sof_abi_hdr.size from ucontrol before copying. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 00335df9da2011e095f846d645cc2e9fd2907659 Author: Jason Wang Date: Fri Jan 30 13:07:50 2026 +0800 VDUSE: avoid leaking information to userspace commit 9c1523803445ee0348f62b77793266dd981596e0 upstream. The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace. Fixes: 8c773d53fb7b ("vduse: Implement an MMU-based software IOTLB") Cc: stable@vger.kernel.org Signed-off-by: Jason Wang Reviewed-by: Xie Yongji Reviewed-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-ID: <20260130050750.4050-1-jasowang@redhat.com> Signed-off-by: Greg Kroah-Hartman commit 8062ff9d366c4bc4ae775e14eac9a769f20c60dd Author: Zhang Tianci Date: Thu Feb 26 19:55:50 2026 +0800 vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter commit ae9c13b6fd79087cc5a216ee1649b6f012c2a238 upstream. There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Cc: stable@vger.kernel.org Signed-off-by: Zhang Tianci Reviewed-by: Xie Yongji Acked-by: Jason Wang Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260226115550.1814-3-zhangtianci.1997@bytedance.com> Signed-off-by: Greg Kroah-Hartman commit 8adebf07b46df79a0e49a6d4ae384f0db7c91db6 Author: Wentao Liang Date: Tue Jun 9 08:47:30 2026 +0000 mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() commit 21cf8dc478a49e8de039c2739b1646a774cb1944 upstream. When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: vr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced. Cc: stable@vger.kernel.org Fixes: fc922bb0dd94 ("mlxsw: spectrum_router: Use one LPM tree for all virtual routers") Signed-off-by: Wentao Liang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260609084730.215732-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cab468c3c03f4bcd7530ce2783a4140da14efb7b Author: Wentao Liang Date: Tue Jun 9 08:37:09 2026 +0000 mlxsw: fix refcount leak in mlxsw_sp_port_lag_join() commit 41c8c1d65b32beacd8d916a22457b4f6e47f45af upstream. When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join() returns an error without releasing the lag reference obtained by the earlier mlxsw_sp_lag_get(). All other error paths in the function jump to the cleanup label that ends with mlxsw_sp_lag_put(), so this is a single missed release. Fix the leak by replacing the bare 'return err' with a goto to the existing error cleanup label, which will drop the reference safely. Cc: stable@vger.kernel.org Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave") Signed-off-by: Wentao Liang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260609083709.209743-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 708df5274ceec9d9747895a31c733c11b12b264c Author: Przemyslaw Korba Date: Mon May 25 10:38:03 2026 +0200 idpf: add padding to PTP virtchnl structures commit d1e8f9fd6b98307bc8d2863c7baa465d8a5a43be upstream. Add padding to virtchnl2 PTP structures to match the Control Plane expected message sizes: * virtchnl2_ptp_get_dev_clk_time: 8 -> 16 bytes * virtchnl2_ptp_set_dev_clk_time: 8 -> 16 bytes * virtchnl2_ptp_get_cross_time: 16 -> 24 bytes The FW expects the above sizes and PTP negotiation fails due to the mismatch. Previously neither the FW nor the driver checked message/reply sizes strictly, so the problem appeared only after recent validation improvements. reproduction steps: ptp4l -i -m Observe: failed to open /dev/ptp0: Permission denied Fixes: bf27283ba594 ("virtchnl: add PTP virtchnl definitions") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov Reviewed-by: Alexander Lobakin Signed-off-by: Przemyslaw Korba Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 21710f27d55e918c8ff4ce239427bb11291a8bd2 Author: Vincent Donnefort Date: Thu Jul 9 17:00:17 2026 +0100 ring-buffer: Allow sparse CPU masks in ring_buffer_desc() [ Upstream commit 601ddaceb861be7eb557278109966320a6f3478c ] No user currently relies on sparse CPU masks, but the descriptor logic already supports them via linear fallback. Remove the arbitrary limitation. Link: https://patch.msgid.link/20260709160017.1729517-4-vdonnefort@google.com Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Reported-by: Sashiko Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 57e566db78fc48da7f278cb6f4e7ede99d374f55 Author: Vincent Donnefort Date: Thu Jul 9 17:00:16 2026 +0100 tracing/remotes: Fix struct_len in trace_remote_alloc_buffer() [ Upstream commit d471d4f86e8689ad15309e49da8e5e4e9bb9ce87 ] Pre-calculate desc->struct_len up-front in trace_remote_alloc_buffer() with trace_buffer_desc_size() to fix double-counting. While at it, use the accessor __first_ring_buffer_desc(). Link: https://patch.msgid.link/20260709160017.1729517-3-vdonnefort@google.com Fixes: 96e43537af54 ("tracing: Introduce trace remotes") Reported-by: Sashiko Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 81a7b7ddb07efdd8cf30eac6def18b9289b8de1e Author: Vincent Donnefort Date: Thu Jul 9 17:00:15 2026 +0100 tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path [ Upstream commit ec082d0b978b5fb4c11205ccce63587ac94c74e1 ] If page allocation fails in trace_remote_alloc_buffer(), desc->nr_cpus is not yet incremented for the current CPU. As a consequence, on error, half-allocated rb_desc will not be freed in trace_remote_free_buffer(). Increment desc->nr_cpus as soon as the first allocation for the current CPU has succeeded. Link: https://patch.msgid.link/20260709160017.1729517-2-vdonnefort@google.com Fixes: 96e43537af54 ("tracing: Introduce trace remotes") Reported-by: Sashiko Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit c25212f274a5cc34862160e39ba139ea889e3cac Author: Ben Dooks Date: Fri Jul 3 17:23:38 2026 +0100 drm/imagination: make pvr_fw_trace_init_mask_ops static [ Upstream commit c804aadc4ce3dcb34d6f2ecc9a159c148210805a ] The pvr_fw_trace_init_mask_ops is not used outside pvr_fw_trace.c so make it static to avoid the following sparse warning: drivers/gpu/drm/imagination/pvr_fw_trace.c:74:31: warning: symbol 'pvr_fw_trace_init_mask_ops' was not declared. Should it be static? Fixes: c6978643ea1c ("drm/imagination: Validate fw trace group_mask") Reviewed-by: Alessio Belle Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260703162338.2848039-1-ben.dooks@codethink.co.uk Signed-off-by: Alessio Belle Signed-off-by: Sasha Levin commit 1a638c55f2db6cb2296e5e3138015dd8fd9d4aa9 Author: Guangshuo Li Date: Wed Jul 8 20:35:20 2026 +0800 smb: client: fix overflow in passthrough ioctl bounds check [ Upstream commit a4f27ad055392fa164f5649e89a3637b033c5fcc ] smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds. Fixes: 2b1116bbe898 ("CIFS: Use common error handling code in smb2_ioctl_query_info()") Signed-off-by: Guangshuo Li Signed-off-by: Steve French Signed-off-by: Sasha Levin commit bf126747e7bff55e5ba0b1ec10fc5fce99feaed9 Author: Guangshuo Li Date: Wed Jul 8 15:34:22 2026 +0800 drm/xe: free madvise VMA array on L2 flush failure [ Upstream commit 14abbed336a2d1bbd726c25d148d2ec0ff928073 ] xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed. The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl. Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded. Fixes: 4f39a194d41e ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization") Signed-off-by: Guangshuo Li Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com Signed-off-by: Rodrigo Vivi (cherry picked from commit c3a1c3579b1250060da73507a4acef712974c78a) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit c69369057b3080a21d337a5636b074223bf155eb Author: Anas Khan Date: Thu Jul 2 16:58:20 2026 +0530 drm/xe: remove duplicate include [ Upstream commit 91426ce50d14a49bde53b3ad1e48393556ba92cd ] xe_pci.c includes twice, separated only by the include. Drop the redundant second include; this is a non-functional cleanup flagged by scripts/checkincludes.pl. Fixes: 6cad22853cb8 ("drm/xe/kunit: Add stub to read_gmdid") Signed-off-by: Anas Khan Link: https://patch.msgid.link/20260702112820.34675-1-anxkhn28@gmail.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 84ed5b0a925721aaf069d36e18a99db966ff4e80) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 3cf83432e0561aef6d7ec2664909d12d0ff0ffc1 Author: Harman Kalra Date: Thu Jul 2 10:26:16 2026 +0530 octeontx2-af: fix VF bringup affecting PF promiscuous state [ Upstream commit fabb881df322da25442f98d23f5fa371e3c78ec4 ] Mbox handling of nix_set_rx_mode for a VF with promiscuous and all_multi flags set to false causes deletion of the PF's promiscuous and allmulti MCAM rules. This occurs because the APIs that enable/disable these rules operate only on the PF, even when the mbox request is made via a VF interface. Guard both rvu_npc_enable_allmulti_entry() and rvu_npc_enable_promisc_entry() disable paths with an is_vf() check so that a VF bringing up or tearing down its interface cannot inadvertently clear the PF's MCAM rules. Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature") Signed-off-by: Harman Kalra Signed-off-by: Nitin Shetty J Link: https://patch.msgid.link/20260702045616.3002773-2-nshettyj@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2ae146bcfcc15eed0e2cb8168405bfcbb40f59cd Author: Gal Pressman Date: Mon Jul 6 08:50:17 2026 +0300 ethtool: rss: Fix hfunc and input_xfrm parsing on big endian [ Upstream commit b62869a81a7ce388d1fbb0fac5fa8300ea614d81 ] ETHTOOL_A_RSS_HFUNC and ETHTOOL_A_RSS_INPUT_XFRM are NLA_U32 attributes, but ethnl_rss_set() and ethnl_rss_create_doit() parse them with ethnl_update_u8(), which reads a single byte. On little endian this happens to read the least significant byte and works as long as the value fits in a byte. On big endian it reads the most significant byte, so the requested value is parsed incorrectly. The destination fields in struct ethtool_rxfh_param are u8, so the attribute can't be read directly with ethnl_update_u32(). Cap the hfunc policy at U8_MAX so an out of range value is rejected instead of being silently truncated into the u8 field, and add ethnl_update_u8_u32() to read the full u32 and narrow it into the u8 destination. Fixes: 82ae67cbc423 ("ethtool: rss: support setting hfunc via Netlink") Fixes: d3e2c7bab124 ("ethtool: rss: support setting input-xfrm via Netlink") Fixes: a166ab7816c5 ("ethtool: rss: support creating contexts via Netlink") Reviewed-by: Dragos Tatulea Reviewed-by: Nimrod Oren Signed-off-by: Gal Pressman Link: https://patch.msgid.link/20260706055017.3355806-1-gal@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7b2fbdafc6de4701ccac80311141b1c603118a04 Author: Li RongQing Date: Fri Jul 3 22:14:23 2026 +0800 net/mlx5: Fix L3 tunnel entropy refcount leak [ Upstream commit c914307e1d41c2cb7bcdcbfde4cd2f214f6aa027 ] mlx5_tun_entropy_refcount_inc() counts both VXLAN and L2-to-L3 tunnel reformat entries as entropy-enabling users. The matching decrement path only handled VXLAN, leaving L2-to-L3 tunnel entries counted after release. Handle MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL in mlx5_tun_entropy_refcount_dec() as well so the enabling entry refcount remains balanced. Fixes: f828ca6a2fb6 ("net/mlx5e: Add support for hw encapsulation of MPLS over UDP") Signed-off-by: Li RongQing Reviewed-by: Simon Horman Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260703141423.1723-1-lirongqing@baidu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ddd5ab921fdd2b04ec24cc5ff06055296d227445 Author: Wang Yan Date: Thu Jul 2 10:59:49 2026 +0800 selftests/net: fix EVP_MD_CTX leak in tcp_mmap [ Upstream commit f4ef35efbb49527293309f668ea73ec5de9b8e7a ] In tcp_mmap.c, both child_thread() and main() allocate an EVP_MD_CTX via EVP_MD_CTX_new() when integrity checking is enabled, but neither function releases the context. child_thread() misses the free in its common cleanup block, and main() returns without freeing the context. This results in a SHA256 context leak on every run that uses the ‑i (integrity) option. Add the missing EVP_MD_CTX_free() calls to the appropriate cleanup paths to fix the leak. Fixes: 5c5945dc695c ("selftests/net: Add SHA256 computation over data sent in tcp_mmap") Signed-off-by: Wang Yan Link: https://patch.msgid.link/20260702025949.442523-1-wangyan01@kylinos.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7d84acf641afb68aa8efe40815ef43779ddb12fd Author: Thomas Zimmermann Date: Thu Jul 2 16:50:13 2026 +0200 drm/fb-helper: Only consider active CRTCs for vblank sync [ Upstream commit 06c2b8d7ea2bcb014dd974fc3bc6d128d65d7477 ] Only synchronize fbdev output to the vblank of an active CRTC. Go over the list of CRTCs and pick the first that matches. Fixes warnings as the one shown below [ 77.201354] WARNING: drivers/gpu/drm/drm_vblank.c:1320 at drm_crtc_wait_one_vblank+0x194/0x1cc [drm], CPU#1: kworker/1:7/1867 [ 77.201354] omapdrm omapdrm.0: [drm] vblank wait timed out on crtc 0 This currently happens if the fbdev output is not on CRTC 0. Atomic and non-atomic drivers require distinct code paths. As for other fbdev operations, implement both and select the correct one at runtime. Not finding an active CRTC is not a bug. Do not wait in this case, but flush the display update as before. v4: - avoid possible deadlocks with locking context (Sashiko) v3: - drop excessive state validation (Jani) - acquire plane and CRTC mutices (Sashiko) v2: - move look-up code into separate helper - support drivers with legacy modesetting v1: - see https://lore.kernel.org/dri-devel/1c9e0e24-9c4a-4259-8700-cf9e5fd60ca3@suse.de/ Co-authored-by: H. Nikolaus Schaller Signed-off-by: Thomas Zimmermann Fixes: d8c4bddcd8bcb ("drm/fb-helper: Synchronize dirty worker with vblank") Tested-by: Icenowy Zheng Tested-by: H. Nikolaus Schaller Closes: https://bugs.debian.org/1138033 Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260702145021.226932-1-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 153d1b8b5bc30847eb70ad535f62f289aa9217e6 Author: Timur Tabi Date: Wed Jul 8 18:57:22 2026 -0500 regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK [ Upstream commit d38f8bd771c4999b797d7074b348cf201414bd34 ] Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code. Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies") Signed-off-by: Timur Tabi Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f0eac9c3c3711f24efc2aaf12b8ec3e54a38c214 Author: Zizhi Wo Date: Sat Jul 4 09:53:20 2026 +0800 smb: client: fix busy dentry warning on unmount after DIO [ Upstream commit 75f5c412fa867efa0bf9b646bffe0d912109e84a ] Commit c68337442f03 ("cifs: Fix busy dentry used after unmounting") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb() to solve it. However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release: [dio] [cifsd] [close + umount] netfs_unbuffered_write_iter_locked ... cifs_demultiplex_thread netfs_unbuffered_write cifs_issue_write netfs_wait_for_in_progress_stream [1] ... netfs_write_subrequest_terminated netfs_subreq_clear_in_progress netfs_wake_collector // wake [1] netfs_put_subrequest netfs_put_request queue_work(system_dfl_wq, xxx) [2] // dio write return cifs_close _cifsFileInfo_put // cfile->count 2->1 --cfile->count [3] // umount cifs_kill_sb kill_anon_super // warning triggered! shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request ... _cifsFileInfo_put // cfile->count 1->0 --cfile->count queue_work(fileinfo_put_wq, xxx) [fileinfo_put_wq] [6] cifsFileInfo_put_work cifsFileInfo_put_final dput If the umount path is triggered before [5], it results warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test} still in use (1) [unmount of cifs cifs] The existing per-inode ictx->io_count wait in cifs_evict_inode() does not help: it lives in the inode eviction path, which runs after shrink_dcache_for_umount() has already warned about the busy dentries. Fix it by adding a per-superblock outstanding-rreq counter that is incremented in cifs_init_request() and decremented in cifs_free_request(). In cifs_kill_sb(), before kill_anon_super(), wait for this counter to reach 0 - which guarantees that all cleanup_work for this sb have run and thus all relevant cfile puts are queued on fileinfo_put_wq or serverclose_wq. Then drain the workqueue so the dentry refs are dropped. This is a targeted wait, not a flush of the system-wide system_dfl_wq. Fixes: 340cea84f691c ("cifs: open files should not hold ref on superblock") Signed-off-by: Zizhi Wo Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b69ea153d30ce19ca8997eeeca1e2219fae5a29b Author: Cao Guanghui Date: Wed Jun 17 14:00:52 2026 +0800 dm era: fix NULL pointer dereference in metadata_open() [ Upstream commit 9ae672606c17891d90b282e3490b817620549599 ] metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern. Fixes: eec40579d848 ("dm: add era target") Signed-off-by: Cao Guanghui Reviewed-by: Su Yue Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit d49f6d098ed48775b9d27a9f9c5c220fdf76f102 Author: Chuck Lever Date: Mon May 4 06:28:19 2026 -0400 SUNRPC: pin upper rpc_clnt across the TLS connect_worker [ Upstream commit 46bc86c833956219bbfd246c1ffd832a479c5199 ] The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction. Reported-by: Michael Nemanov Closes: https://lore.kernel.org/linux-nfs/40e3d522-dfcf-4fc1-9c55-b5e81f1536d5@vastdata.com/ Fixes: 75eb6af7acdf ("SUNRPC: Add a TCP-with-TLS RPC transport class") Signed-off-by: Chuck Lever Tested-by: Michael Nemanov Reviewed-by: Michael Nemanov Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9359aac4999e99d5eb5d6fe17c4ed1fea9c5946b Author: Chuck Lever Date: Mon May 4 06:28:18 2026 -0400 SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED [ Upstream commit 29bacb096d43bd04062f6655e50ceeed27fe6d2f ] xs_tcp_tls_setup_socket() creates a temporary "lower" rpc_clnt with rpc_create() to drive the inner TLS handshake, then waits for XPRT_LOCKED on its xprt with TASK_KILLABLE so a stuck handshake can be aborted by signal. When the wait is interrupted, the function jumps to out_unlock without releasing lower_clnt. The success path and the out_close error path both call rpc_shutdown_client(lower_clnt); only the killed-wait path skips it, leaking the clnt and its underlying xprt. Call rpc_shutdown_client() on this path before joining out_unlock. xprt_release_write() is not needed here because XPRT_LOCKED was never acquired. Fixes: 26e8bfa30dac ("SUNRPC/TLS: Lock the lower_xprt during the tls handshake") Signed-off-by: Chuck Lever Tested-by: Michael Nemanov Reviewed-by: Michael Nemanov Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c37abc99bb3de3d3219ecef253d649f74117fd83 Author: Guangshuo Li Date: Wed Jul 8 19:27:10 2026 +0800 cifs: validate DFS referral string offsets [ Upstream commit 027a84ac6b50c12ef767c15abfc58aa865820e9e ] parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer. Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Signed-off-by: Guangshuo Li Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b0640acace2543c7c0932602c22f46eff9573717 Author: Rongguang Wei Date: Fri Jun 26 13:58:20 2026 +0800 s390/zcrypt: Remove the empty file [ Upstream commit 575f87b9d4882b0d621192fdd754d7e09dbd5789 ] The files has no real user because CEX2 and CEX3 device drivers are removed, also remove these empty files. Fixes: 5ac8c72462cd ("s390/zcrypt: remove CEX2 and CEX3 device drivers") Signed-off-by: Rongguang Wei Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 92185d6f7819bc558939ae83de7b1abe90e3b5c2 Author: Julian Anastasov Date: Tue Jul 7 21:25:46 2026 +0300 ipvs: ensure inner headers in ICMP errors are in headroom [ Upstream commit 3f7a535ff0fa627a0132803e4c2f903ceffcbc1c ] Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers. Fixes: f2edb9f7706d ("ipvs: implement passive PMTUD for IPIP packets") Link: https://sashiko.dev/#/patchset/20260702073430.67680-1-zhaoyz24%40mails.tsinghua.edu.cn Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f0f35153de83912da227f4b54d1290e18442efe2 Author: Yizhou Zhao Date: Thu Jul 2 15:34:28 2026 +0800 ipvs: fix PMTU for GUE/GRE tunnel ICMP errors [ Upstream commit 6b335af0d0d1ff44ac579d106953bf19299e5233 ] When an ICMP Fragmentation Needed error is received for a tunneled IPVS connection, ip_vs_in_icmp() recomputes the MTU that the original packet can use by subtracting the tunnel overhead from the reported next-hop MTU. The current code always subtracts sizeof(struct iphdr), which is only the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and ipvs_gre_decap() already compute the additional tunnel header length, but that value is scoped to the decapsulation block and is lost before the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to the client advertises an MTU that is too large, so PMTUD can fail to converge for GUE/GRE-tunneled real servers. With a reported next-hop MTU of 1400, a GUE tunnel currently returns 1380 to the client. The correct value is 1368: 1400 - sizeof(struct iphdr) - sizeof(struct udphdr) - sizeof(struct guehdr) Hoist the tunnel header length into the main ip_vs_in_icmp() scope and subtract sizeof(struct iphdr) + ulen in the Fragmentation Needed path. The IPIP path keeps ulen as 0, so its existing 1400 - 20 = 1380 result is unchanged. Fixes: 508f744c0de3 ("ipvs: strip udp tunnel headers from icmp errors") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Stable-dep-of: 3f7a535ff0fa ("ipvs: ensure inner headers in ICMP errors are in headroom") Signed-off-by: Sasha Levin commit c2ee845e292c278fac75bf28d96bc892607fd5c4 Author: Yizhou Zhao Date: Mon Jul 6 18:16:23 2026 +0800 ipvs: use parsed transport offset in TCP state lookup [ Upstream commit 2500fa3958b1ba51c2b065e39db1b04dfa7e23a2 ] TCP state handling reparses the skb to find the TCP header. For IPv6 it uses sizeof(struct ipv6hdr), while the surrounding IPVS code already parsed the packet with ip_vs_fill_iph_skb() and has the real transport-header offset in iph.len. This makes TCP state handling look at the wrong bytes when an IPv6 packet carries extension headers. Use the parsed transport offset passed down from ip_vs_set_state() when reading the TCP header. For IPv4 and for IPv6 packets without extension headers, the passed offset matches the previous value. Fixes: 0bbdd42b7efa6 ("IPVS: Extend protocol DNAT/SNAT and state handlers") Link: https://lore.kernel.org/netdev/20260705125659.37744-1-zhaoyz24@mails.tsinghua.edu.cn/ Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: Claude Code:GLM-5.2 Signed-off-by: Yizhou Zhao Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 568720055fbde64a575df08e0daf972d1c955114 Author: Yizhou Zhao Date: Mon Jul 6 18:16:22 2026 +0800 ipvs: pass parsed transport offset to state handlers [ Upstream commit bae7ce7bafb59e42dc0e0e2999fdd9d1cffe3866 ] IPVS callers already parse the packet into struct ip_vs_iphdr before updating connection state. For IPv6 this records the real transport-header offset after extension headers in iph.len. Pass this parsed transport offset through ip_vs_set_state() and the protocol state_transition() callback so protocol handlers can use the same packet context as scheduling and NAT handling. This patch only changes the common callback plumbing and adapts the protocol callback signatures; TCP and SCTP start using the value in follow-up patches. Signed-off-by: Yizhou Zhao Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Stable-dep-of: 2500fa3958b1 ("ipvs: use parsed transport offset in TCP state lookup") Signed-off-by: Sasha Levin commit ef0c7d4b04a0e6ad175323c24bc84e11470dd79d Author: Tamaki Yanagawa Date: Fri Jul 3 16:22:57 2026 +0000 netfilter: nft_lookup: fix catchall element handling with inverted lookups [ Upstream commit e6107a4c74b54cb33e3bce162a63048ae5a6b198 ] nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, "!= @set") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval(). Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support") Signed-off-by: Tamaki Yanagawa Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 95128dc74425ec19ed4f2077ccc651e791ff4b75 Author: Eric Dumazet Date: Sun Jul 5 18:17:56 2026 +0000 ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer() [ Upstream commit 3546deaa0c30a14c7cdb5dc8f2432cb428f0cd36 ] When a timer is deleted and not re-armed in igmp_mod_timer(), or stopped in igmp_stop_timer(), the code currently decrements the reference counter of the multicast list entry @im using refcount_dec(&im->refcnt). However, both functions can be called from the RCU reader path: - igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu() - igmp_stop_timer() via igmp_rcv() -> igmp_heard_report() If the group im was concurrently removed from the list by ip_mc_dec_group(), its reference count might have already been decremented to 1. In this case, timer_delete() succeeds, and refcount_dec() decrements the refcount from 1 to 0. Since refcount_dec() does not free the object when it hits 0 (unlike ip_ma_put()), the im structure is leaked. Fix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt), and deferring the put until after the spinlock is released. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260705181756.963063-4-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1fcabcba272d995759ded8df68145ee05177ee9c Author: Yuyang Huang Date: Fri Jun 5 10:43:18 2026 +0900 ipv4: igmp: annotate data-races around timer-related fields [ Upstream commit 3289d17b7a1321e103b8aec4ad82675c03c4764f ] /proc/net/igmp walks the multicast list locklessly under RCU and reads timer-related fields (im->tm_running, im->reporter, im->timer.expires) to print the timer state of multicast memberships. Concurrently, these fields are modified under im->lock spinlock in timer management paths (igmp_stop_timer(), igmp_start_timer(), and igmp_timer_expire()). Fix this intentional lockless snapshot by annotating the lockless reads with READ_ONCE() and the updates with WRITE_ONCE(). Signed-off-by: Yuyang Huang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260605014318.3890804-3-yuyanghuang@google.com Signed-off-by: Paolo Abeni Stable-dep-of: 3546deaa0c30 ("ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer()") Signed-off-by: Sasha Levin commit 16e5b2dbea49ad685084f9bb0cbe599563f1dd5f Author: Yuyang Huang Date: Fri May 22 18:39:06 2026 +0900 ipv4: igmp: annotate data-races around im->users [ Upstream commit 061c0aa740d5d3847cd600a74c66a165bee1fbe0 ] /proc/net/igmp walks IPv4 multicast memberships under RCU and prints im->users without holding RTNL, while multicast join and leave paths update the field while holding RTNL. Annotate this intentional lockless snapshot with READ_ONCE() and the matching writers with WRITE_ONCE(). Signed-off-by: Yuyang Huang Reviewed-by: Jiayuan Chen Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260522093906.39764-1-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 3546deaa0c30 ("ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer()") Signed-off-by: Sasha Levin commit 0458ba1cda830ba4ccfcd9e19c0891438bcdbe4e Author: Eric Dumazet Date: Sun Jul 5 18:17:55 2026 +0000 ipv6: mcast: Fix potential UAF in MLD delayed work [ Upstream commit 9b26518b6896a16b809b1e42986f4ebac7bccc1e ] A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260705181756.963063-3-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8d4394ffa40508e0de72f464af351f6ca6a6cdc3 Author: Eric Dumazet Date: Sun Jul 5 18:17:54 2026 +0000 ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() [ Upstream commit 7b19c0f81ed1fdaec6bc522569be367199a9edf3 ] A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Zero Day Initiative Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260705181756.963063-2-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d73e4d790db611da7439e78a6ab6cb32e7885ab8 Author: Rosen Penev Date: Tue Jul 7 16:23:58 2026 -0700 gpio: mvebu: free generic chips on unbind [ Upstream commit b11c513ad943f35cf5e8007d3a56279c79b7ed4b ] irq_alloc_domain_generic_chips() allocates generic chip data that must be freed via irq_domain_remove_generic_chips(). The devres action mvebu_gpio_remove_irq_domain() only called irq_domain_remove(), which only frees the generic chips if IRQ_DOMAIN_FLAG_DESTROY_GC is set. Call irq_domain_remove_generic_chips() explicitly before irq_domain_remove() instead. Fixes: 812d47889a8e ("gpio/mvebu: Use irq_domain_add_linear") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260707232358.1218077-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 46d0fd8535edce31f15e48d2de1bdee39a4850e5 Author: Sandipan Das Date: Wed Jul 8 16:02:04 2026 +0530 perf/x86/amd/core: Avoid enabling BRS from the SVM reload path [ Upstream commit 07c60dda9c059c09f83d42a3ebda2e7cc1cf3bc2 ] Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbr_users. When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amd_pmu_enable_all() to rewrite the event selectors. However, amd_pmu_enable_all() also calls amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP: Call Trace: amd_pmu_enable_all+0x1d/0x90 amd_pmu_disable_virt+0x62/0xb0 kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm] hardware_disable_nolock+0x1a/0x30 [kvm] __flush_smp_call_function_queue+0x9b/0x410 __sysvec_call_function+0x18/0xc0 sysvec_call_function+0x69/0x90 asm_sysvec_call_function+0x16/0x20 RIP: 0010:cpuidle_enter_state+0xc4/0x450 ? cpuidle_enter_state+0xb7/0x450 cpuidle_enter+0x29/0x40 cpuidle_idle_call+0xf5/0x160 do_idle+0x7b/0xe0 cpu_startup_entry+0x26/0x30 start_secondary+0x115/0x140 secondary_startup_64_no_verify+0x194/0x19b Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbr_users > 0. Fixes: bae19fdd7e9e ("perf/x86/amd/core: Fix reloading events for SVM") Signed-off-by: Sandipan Das Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Link: https://patch.msgid.link/702fa204d574b03d14e3664c7d4b201db048bbfd.1783506528.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit 543c66cea0e24a49b3b5468c16655fee56832f77 Author: Suman Ghosh Date: Thu Jul 2 09:04:51 2026 +0530 octeontx2-pf: check DMAC extraction support before filtering [ Upstream commit 235acadd310533ba386ae61ad155b72bee381559 ] Currently, configuring a VF MAC address via the PF (e.g., 'ip link set vf 0 mac ') blindly attempts to install a DMAC-based hardware filter. However, the hardware parser profile might not support DMAC extraction. Check if the hardware parsing profile supports DMAC extraction before adding the filter. Additionally, emit a warning message to inform the operator if the MAC filter installation fails due to missing DMAC extraction support. Update config->mac only after hardware programming succeeds in otx2_set_vf_mac(). Fixes: f0c2982aaf98 ("octeontx2-pf: Add support for SR-IOV management functions") Signed-off-by: Suman Ghosh Signed-off-by: Nitin Shetty J Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260702033451.2969880-1-nshettyj@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f1e7807df5bf2d42a40266430e9f82f37633cdcf Author: Samuel Moelius Date: Thu Jul 2 00:07:59 2026 +0000 net/sched: cake: reject overhead values that underflow length [ Upstream commit b7f97cae7ec1b6c3c32843c42be218690d310467 ] CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments. Fixes: a729b7f0bd5b ("sch_cake: Add overhead compensation support to the rate shaper") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260702000758.297407.e5c888d9d99d.cake-overhead-underflow@trailofbits.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e3d1ca7882a529a90ccbe6c9e2c7bd8d92caf84f Author: Rosen Penev Date: Wed Jul 1 20:26:52 2026 -0700 net: mdio: select REGMAP_MMIO instead of depending on it [ Upstream commit 1a3267a8c9ecabb8e27f5cbda6d19295d5e41beb ] REGMAP_MMIO is a hidden (non-user-visible) tristate symbol. Using depends on it is incorrect because there is no way for the user to enable it directly. Change to select, which is the convention used by every other driver in the tree that needs REGMAP_MMIO. Fixes: 8057cbb8335c ("net: mdio: mscc-miim: Add depend of REGMAP_MMIO on MDIO_MSCC_MIIM") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260702032653.1580616-1-rosenp@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3861bae3ffe43fa9612244a452d3c340d5fc3c73 Author: Cihan Karadag Date: Tue Jul 7 17:57:05 2026 -0600 selftests: gpio: add gpio-cdev-uaf to .gitignore [ Upstream commit 4ad805f0e41acf56ac54855c666d34c59ad66fe7 ] Commit c7f92042d3f3 ("selftests: gpio: Add gpio-cdev-uaf tests") added the gpio-cdev-uaf binary to TEST_GEN_PROGS_EXTENDED but never added it to .gitignore. Building it with: make -C tools/testing/selftests/gpio TARGETS=gpio leaves gpio-cdev-uaf as an untracked file. Fixes: c7f92042d3f3 ("selftests: gpio: Add gpio-cdev-uaf tests") Signed-off-by: Cihan Karadag Reviewed-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260707235707.1349969-1-cihan.cihan@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5d65dade4d84913d1879f3db6a12ac007e08314b Author: Maíra Canal Date: Fri Jul 3 12:33:35 2026 -0300 drm/v3d: Reject invalid indirect BO handle in indirect CSD setup [ Upstream commit 2f8b8593c7832fad655290cef9e99af05b1b52b3 ] v3d_get_cpu_indirect_csd_params() looks up the indirect buffer object from a userspace-supplied handle but never checks the result. A bogus or stale handle makes drm_gem_object_lookup() return NULL, which is then stored in info->indirect and only dereferenced later when the indirect CSD job runs, turning a userspace mistake into a NULL pointer dereference in the kernel. Bail out with -ENOENT as soon as the lookup fails, so the bad handle is rejected at submission time. Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job") Reviewed-by: Iago Toral Quiroga Signed-off-by: Maíra Canal Link: https://patch.msgid.link/20260703-v3d-cpu-job-fixes-v3-2-bc51b1f3eeb5@igalia.com Signed-off-by: Sasha Levin commit 91e8109ecffb925b6202d2737384df285b195bfb Author: Lizhi Hou Date: Mon Jul 6 15:12:28 2026 -0700 accel/amdxdna: Fix potential amdxdna_umap lifetime race [ Upstream commit 14f172eff9c19f8043a9858845f33cd034f3a41e ] amdxdna_umap_release() calls the blocking mmu_interval_notifier_remove() before removing the object from abo->mem.umap_list. If aie2_populate_range() runs concurrently, it may obtain a reference to an amdxdna_umap that is being released, leading to a potential use-after-free. Use kref_get_unless_zero() in aie2_populate_range() when acquiring a reference. If the reference count has already dropped to zero, release is in progress and the entry is skipped. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260706221228.434099-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 6cb18e712feb1cfaabd087a98a6f4d27a894a6af Author: Ben Dooks Date: Wed Jun 17 11:58:22 2026 +0100 tracing: Make tracepoint_printk static as not exported [ Upstream commit d5c6785f94ead7cd76b38af301ac63cb673485bc ] The tracepoint_printk symbol is not exported, so make it static to remove the following sparse warning: kernel/trace/trace.c:90:5: warning: symbol 'tracepoint_printk' was not declared. Should it be static? Fixes: dd293df6395a2 ("tracing: Move trace sysctls into trace.c") Link: https://patch.msgid.link/20260617105822.904164-1-ben.dooks@codethink.co.uk Signed-off-by: Ben Dooks Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 170c008d3f49a5774d078d8a9206e2239f2e1bc2 Author: Robert Mader Date: Fri Jul 3 09:32:30 2026 +0200 drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE [ Upstream commit ac7c6b4308c5e757eb278d47b9c0761c31ac9d6b ] The client cap is currently advertised unconditionally, even for drivers that do not support plane color pipelines. If clients supporting the latter, like Wayland compositors or tools like drm_info, enable the client cap on such drivers they will be left without both color pipeline and the legacy properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB conversion support. Prevent that by only marking the cap supported if there are actually planes with color pipelines. Note: while the color pipeline replacement for the legacy properties is still under review (1), we can assume that it will work as a drop-in replacement. That means any plane on any hardware currently supporting the legacy properties will be able to offer a functionally equal color pipeline and there will be no technical reason keep using the legacy properties if both the driver and the client support the new API. [1] https://lore.kernel.org/dri-devel/20260623164812.81110-1-harry.wentland@amd.com/ Signed-off-by: Robert Mader Reviewed-by: Chaitanya Kumar Borah Reviewed-by: Melissa Wen Fixes: 179ab8e7d7b3 ("drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE") Link: https://patch.msgid.link/20260703073230.19982-1-robert.mader@collabora.com Suggested-by: Maarten Lankhorst Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 82202fc724f44cf599f7740cb4cd5ea5171eba67 Author: Jia Wang Date: Thu Jul 2 17:22:12 2026 +0800 gpio: dwapb: Defer clock gating until noirq [ Upstream commit d775b9451eb8f52021dea6483ad758fef81dbf1e ] GPIO consumers such as gpio-keys can enable IRQ wake and adjust the wake trigger type from their suspend callbacks. If the DWAPB controller suspends first, masking interrupts and disabling its clocks in the normal suspend phase prevents that late wake configuration from reliably reaching the hardware. Systems with real DWAPB bus clocks then fail to wake from s2idle through GPIO keys. Save the register context in the normal suspend callback, but defer IRQ masking and clock gating until suspend_noirq. At that point all consumers have finished configuring wake IRQs, so keep the clocks enabled when wake lines are armed and only gate them when no wake source is active. Resume_noirq reenables clocks, if they were gated, before the normal resume path restores registers. Propagate wake requests to the parent irqchip while keeping the local wake mask in sync with failures. Fixes: 6437c7ba69c3 ("gpio: dwapb: Add wakeup source support") Signed-off-by: Jia Wang Link: https://patch.msgid.link/20260702-gpio-dwapb-wakeup-v2-1-203f2f33429f@ultrarisc.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 8aede22b6a6948ab608c15c0086139295e8c94b1 Author: Enrico Pozzobon Date: Wed Jul 1 16:47:23 2026 +0200 net: usb: lan78xx: disable VLAN filter in promiscuous mode [ Upstream commit 60444706aa17616efc03190d099ac347e28b3d0a ] The hardware VLAN filter (RFE_CTL_VLAN_FILTER_) drops VLAN-tagged frames whose VID has not been registered via lan78xx_vlan_rx_add_vid(). It is left enabled in promiscuous mode, so packet capture (e.g. tcpdump or Wireshark) does not see tagged frames for unregistered VIDs. Clear the filter while the interface is promiscuous and restore it from NETIF_F_HW_VLAN_CTAG_FILTER otherwise. Enforce the same condition in lan78xx_set_features() so netdev_update_features() cannot re-enable the filter while promiscuous. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Enrico Pozzobon Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260701-lan78xx-vlan-promisc-v3-1-232266d32743@dissecto.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 81acef3a247fd523513a2e9f71de1c167bc0f882 Author: Yuho Choi Date: Wed Jul 1 00:08:47 2026 -0400 net/liquidio: drop cached VF pci_dev LUT [ Upstream commit 5c0e3ba4f500fd4314ceb42f07f16bc445156431 ] The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup. Fixes: ca6139ffc67ee ("liquidio CN23XX: sysfs VF config support") Fixes: 8c978d059224 ("liquidio CN23XX: Mailbox support") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260701040847.1897845-1-dbgh9129@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 40824fc26ad318dc9e65db1907843afc673b298d Author: Dong Yibo Date: Wed Jul 1 11:22:08 2026 +0800 net: rnpgbe: fix mailbox endianness and remove pointer casts [ Upstream commit d9d6d67f4c0877fde783c9d5beee013bcf1b1e85 ] The rnpgbe mailbox exchanges data through 32-bit MMIO registers in little-endian wire format. The original code had two problems: 1. FW structs (with __le16/__le32 fields) were cast to (u32 *) before reaching the mailbox transport, hiding the endian annotations from sparse. 2. No cpu_to_le32()/le32_to_cpu() conversion was done between CPU-endian MMIO values and the little-endian payload, causing data corruption on big-endian systems. Fix by adding the missing byte-order conversions in the transport layer and introducing union wrappers (mbx_fw_cmd_req_u, mbx_fw_cmd_reply_u) that overlay each FW struct with a __le32 dwords[] array. Callers fill named fields using cpu_to_le16/32(), then pass dwords[] to the transport, which now takes explicit __le32 * instead of u32 *. This eliminates all pointer casts on the mailbox data path and lets sparse verify the conversions. Fixes: 4543534c3ef5 ("net: rnpgbe: Add basic mbx ops support") Signed-off-by: Dong Yibo Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260701032208.1843156-2-dong100@mucse.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ebc295ce343600c2d60c1e1e0c5d192080217457 Author: Chuck Lever Date: Tue Jun 30 15:15:51 2026 -0400 net/tls: Consume empty data records in tls_sw_read_sock() [ Upstream commit 3be28e2c9cd0230cb51fd4967df095273afd3848 ] A peer may send a zero-length TLS application_data record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has full_len == 0. tls_sw_read_sock() hands it to the read_actor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rx_list, and stops. rx_list is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it. tls_sw_recvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consume_skb(). Mirror that in the read_sock() path by recognizing an empty data record before the actor runs, consuming it, and continuing. Fixes: 662fbcec32f4 ("net/tls: implement ->read_sock()") Signed-off-by: Chuck Lever Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260630191551.875664-1-cel@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bea20225c67fed9be3e98619c77af6ee3f43fe07 Author: Lizhi Hou Date: Mon Jun 8 18:12:42 2026 -0700 accel/amdxdna: Fix VMA access race [ Upstream commit 1ba02717e821cf14ece642273958647e79698d3d ] aie2_populate_range() and amdxdna_umap_release() access a saved VMA pointer that may have already been freed, leading to a potential use-after-free. Remove the VMA accesses from these functions to avoid the race. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260609011242.2833740-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit cf10c506fdbea7f4f05998f85aee65a1237aed1d Author: Lizhi Hou Date: Mon Jun 15 23:15:32 2026 -0700 accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register() [ Upstream commit 18aaebdf43366954345a6721ed2bff3ac3c9fa61 ] nr_pages is declared as u32 in amdxdna_hmm_register(), which may not be large enough to represent the number of pages for large mappings. Use unsigned long for nr_pages to avoid potential overflow. Fixes: ac49797c1815 ("accel/amdxdna: Add GEM buffer object management") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260616061532.3533469-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 2d8eeb0578ae3aadf112fd3e1997e58178f75979 Author: Lizhi Hou Date: Tue Jun 16 14:24:29 2026 -0700 accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo() [ Upstream commit e35c9cf5512814fb04f369f2eada64f0a7164609 ] amdxdna_hwctx_sync_debug_bo() invokes the hardware hwctx_sync_debug_bo() callback while holding xdna->dev_lock. The callback may call amdxdna_cmd_submit(), which in turn calls amdxdna_pm_resume_get(). If the device is suspended, amdxdna_pm_resume_get() may synchronously execute amdxdna_pm_resume(), which also acquires xdna->dev_lock, resulting in a deadlock. Avoid the deadlock by calling amdxdna_pm_resume_get() before holding xdna->dev_lock in both amdxdna_hwctx_sync_debug_bo() and amdxdna_drm_config_hwctx_ioctl() Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260616212429.3620645-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992 Author: Hui Wang Date: Sun Jun 7 15:24:30 2026 +0800 ring-buffer: Fix event length with forced 8-byte alignment [ Upstream commit c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0 ] When RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length() reserves the space of event->array[0] for placing the data length and rb_update_event() stores the data length in event->array[0] accordingly. As a result the whole event length will add extra 4 bytes for sizeof(event.array[0]) unconditionally. But ring_buffer_event_length() only subtracts the sizeof(event->array[0]) for events larger than RB_MAX_SMALL_DATA + sizeof(event->array[0]). As a result, small events on architectures with RB_FORCE_8BYTE_ALIGNMENT=true report a data length that is 4 bytes larger than expected. To fix it, add the RB_FORCE_8BYTE_ALIGNMENT as a condition to subtract the size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is true. This issue is observed in a riscv64 kernel with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace selftest trace_marker_raw.tc, we get the weird log: for cases where the id is 1..100, the number of data field is 8*N, but once id exceeds 100, the number of data field becomes 8*N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 8*1) ... # a buf: 58 ... (number of data field is 8*2) ... # 64 buf: 58 ... (number of data field is 8*13) # 65 buf: 58 ... (number of data field is 8*13+4) After applying this change, the number of data field keeps being 8*N+4 consistently. Link: https://patch.msgid.link/20260607072431.125633-2-hui.wang@canonical.com Fixes: 2271048d1b3b ("ring-buffer: Do 8 byte alignment for 64 bit that can not handle 4 byte align") Signed-off-by: Hui Wang Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit d0a2b0c81f112540a337cde1c20251bf05ddf1da Author: Stig Hornang Date: Fri Jun 12 16:38:18 2026 +0200 Bluetooth: L2CAP: fix tx ident leak for commands without a response [ Upstream commit 6e1930ece855a4c256f1c7e6632d634cfb9888b5 ] Commit 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident") changed ident allocation to use an IDA, releasing idents in l2cap_put_ident() when the matching response command is received. But identifiers allocated for commands that have no response defined are never released. In particular L2CAP_LE_CREDITS is sent repeatedly for the lifetime of an LE CoC channel, so a peer streaming data to the host exhausts the 1-255 ident range after 254 credit packets. From then on l2cap_get_ident() fails: kernel: Bluetooth: Unable to allocate ident: -28 and every subsequent L2CAP_LE_CREDITS packet is sent with ident 0, which is invalid (Core Spec, Vol 3, Part A, Section 4: "Signaling identifier 0x00 is an invalid identifier and shall never be used in any command"). Remote stacks that validate the ident drop these commands, never receive new credits, and the channel stalls permanently. With default socket buffers this happens after roughly 0.5 MB of received data (the exact amount depends on the socket receive buffer): < ACL Data TX: Handle 2048 flags 0x00 dlen 12 LE L2CAP: LE Flow Control Credit (0x16) ident 0 len 4 Source CID: 64 Credits: 1 Release the ident immediately after sending L2CAP_LE_CREDITS since no response will ever release it. Use a local variable instead of chan->ident so that an ident that an EXT_FLOWCTL channel may be waiting on (e.g. a pending reconfigure) is not overwritten by a credit packet. Also add the missing L2CAP_LE_CONN_RSP case to l2cap_put_ident() so idents allocated for outgoing L2CAP_LE_CONN_REQ commands are released when the response arrives. Fixes: 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221629 Assisted-by: Claude:claude-opus-4.8 Assisted-by: Fable:5 Signed-off-by: Stig Hornang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a8e169d308775039200bb9c905c7ce420db6e8c5 Author: Weiming Shi Date: Wed Jul 1 09:06:14 2026 -0700 Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() [ Upstream commit dd068ef044128db655f48323a4acfd5907e04903 ] bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at skb->data + 1, without checking the length: bt_dev_info(hdev, "%s", (char *)(skb->data + 1)); hci_set_fw_info(hdev, "%s", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded "%.*s" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working. Fixes: ddd68ec8f484 ("Bluetooth: bpa10x: Read revision information in setup stage") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Reported-by: Xiang Mei Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 058d0d087a271671e1bd71823ac0c752e8d6840c Author: Pauli Virtanen Date: Wed Jul 1 18:46:39 2026 +0300 Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length [ Upstream commit fd076d8deeab6f9f18ef13400f89e1f550df665b ] slen contains ISO_SDU_Length (12 bits), RFU (2 bits), Packet_Status_Flags (2 bits). Exclude the RFU bits from hci_iso_data_len. Also add masks to the pack macro. Fixes: 4de0fc599eb9 ("Bluetooth: Add definitions for CIS connections") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 990e65eb9387c4ddfa7f68782b6644c2c35d489f Author: Pauli Virtanen Date: Wed Jul 1 18:46:38 2026 +0300 Bluetooth: ISO: fix malformed ISO_END/CONT handling [ Upstream commit e054c1a6ae7310d2815778fddb87da616e11c255 ] Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. If controller sends too short ISO_END we accept it. Fix by marking unfinished ISO_START via conn->rx_skb != NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets. Fixes: 84c24fb151fc ("Bluetooth: ISO: drop ISO_END frames received without prior ISO_START") Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1f9375f55ead8fb96a8157956900c45423933004 Author: Kiran K Date: Tue Jun 30 22:29:19 2026 +0530 Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe() [ Upstream commit 9c36951474d8e1127f4946f39cb874a200f34e9f ] The FLR branch in btintel_pcie_reset_work() open-coded the entire re-init sequence: btintel_pcie_release_hdev() (hci_unregister_dev + hci_free_dev), pci_try_reset_function(), enable_interrupts / config_msix / enable_bt / reset_ia / start_rx, then btintel_pcie_setup_hdev() (hci_alloc_dev_priv + hci_register_dev). Every probe() init step had to be kept in sync with this second copy in the reset path, and any failure mid-sequence left state to unwind by hand. The PLDR path already delegates teardown and re-init to the PCI core via device_reprobe(): .remove() destroys data through devres and unregisters hdev, then .probe() rebuilds everything from scratch. Apply the same model to FLR. Introduce btintel_pcie_perform_flr() mirroring perform_pldr(). It runs pci_try_reset_function() (required to avoid the device_lock ABBA against btintel_pcie_remove(), which calls disable_work_sync(&reset_work) while holding device_lock) followed by device_reprobe(). On success, data is destroyed and a fresh probe re-INIT_WORKs coredump_work with disable count 0, so enable_work() must not be called; on failure, data is still alive and the caller balances the earlier disable_work_sync(). The contract is documented on the helper and reiterated at the reset_work() call site. reset_work() shrinks to interrupt/worker drain, dispatch on reset_type, and the single asymmetry between the two paths. The out_enable label, the manual unregister/register pair, and the forward declaration of btintel_pcie_setup_hdev() are dropped. No intended functional change; FLR and PLDR now share one teardown contract. Fixes: 256ab9520d15 ("Bluetooth: btintel_pcie: Support Function level reset") Assisted-by: GitHub-Copilot:claude-4.7-opus Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c36895aa1122f8e3f917bf767f9ab59c39280d9d Author: Ravindra Date: Wed Jun 10 21:55:44 2026 +0530 Bluetooth: btintel_pcie: Separate coredump work from RX work [ Upstream commit f70f7f2512c6b9113dc78f6a25361166afd1412e ] Sharing a single workqueue between coredump processing and RX delays evacuation of RX events while a coredump is in progress. The firmware's RX buffers can overflow during that window, leading to dropped events. The issue was observed in HID use cases where HID reports arrive in bursts and quickly fill the RX path while a coredump is being collected. Move coredump processing to a dedicated ordered coredump_workqueue with its own coredump_work, so coredumps run independently of RX. All four coredump trigger sources (FW assert, HW exception, user sysfs trigger, and resume-error detection) are switched to this new workqueue. Ordering serialises concurrent triggers without blocking RX. Signed-off-by: Ravindra Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 9c36951474d8 ("Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()") Signed-off-by: Sasha Levin commit fb6fc74cc10f0ee869bc5af9e2fd0d5c787ababf Author: Kiran K Date: Wed Jun 3 21:24:15 2026 +0530 Bluetooth: btintel_pcie: Add support for smart trigger dump [ Upstream commit 975a70ff0aec8a2be0d633113f781b301db4a816 ] Based on the debug configuration, firmware can raise MSI-X interrupt with firmware trigger cause bit set on specific events like Disconnection, Connection Timeout, Page Timeout etc. Upon receiving an MSI-X interrupt with the firmware trigger cause bit set, the driver performs the following actions: 1. Reads Device Memory: Retrieves data from the device memory, constructs an HCI diagnostic event, and sends it to the monitor. This event includes details about the trigger, such as connection timeout or page timeout. 2. Dumps Device Coredump: Generates a coredump containing firmware traces for further analysis. The coredump can be retrieved using: $ cat /sys/class/devcoredump/devcd*/data > /tmp/btintel_coredump.bin HCI traces: = Vendor Diagnostic (len 12) a5 a5 a5 a5 01 03 00 23 00 01 00 00 Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 9c36951474d8 ("Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()") Signed-off-by: Sasha Levin commit 4ff5778e8ee3b533b2e8c506e2d94f28efd89d44 Author: Chandrashekar Devegowda Date: Mon Apr 13 09:50:40 2026 +0530 Bluetooth: btintel_pcie: Support Product level reset [ Upstream commit 2d00975c841fa2e52921353392ce9780843bfee7 ] When driver encounters a TOP exception, ACPI methods will be called for Product level reset since Wifi and BT share the same TOP. BT driver will first reprobe the wifi driver and then reprobe BT. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Venkat Rao Bagalkote Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 9c36951474d8 ("Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()") Signed-off-by: Sasha Levin commit a50da115b5888062d32c86a548a29b4e2559d7ec Author: Sungwoo Kim Date: Wed Jun 24 17:33:04 2026 -0400 Bluetooth: sco: Fix a race condition in sco_sock_timeout() [ Upstream commit 0f8a5dcc66648b6e1458a9f3ba4c5a0463a228fc ] sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/bluetooth/sco.c:1300 __sock_release+0xe1/0x2d0 sect/v6.13-rc4/net/socket.c:640 sock_close+0x1c/0x30 sect/v6.13-rc4/net/socket.c:1408 __fput+0x2bd/0xa80 sect/v6.13-rc4/fs/file_table.c:450 __fput_sync+0x15e/0x1c0 sect/v6.13-rc4/fs/file_table.c:535 __do_sys_close sect/v6.13-rc4/fs/open.c:1554 [inline] __se_sys_close sect/v6.13-rc4/fs/open.c:1539 [inline] __x64_sys_close+0x93/0x120 sect/v6.13-rc4/fs/open.c:1539 do_syscall_x64 sect/v6.13-rc4/arch/x86/entry/common.c:52 [inline] do_syscall_64+0xee/0x210 sect/v6.13-rc4/arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn") Acked-by: Dave Tian Signed-off-by: Sungwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit dbd935a9e056545721bc4e9ce518c775d787b21e Author: Cen Zhang Date: Wed Jun 24 00:13:28 2026 +0800 Bluetooth: MGMT: Fix adv monitor add failure cleanup [ Upstream commit 384a4b2fef9ffe5e270ee5558975c0504881c5fb ] hci_add_adv_monitor() publishes a new adv_monitor in hdev->adv_monitors_idr before the powered MSFT setup step. The MSFT offload add path can then fail either locally before the controller add command completes, or in the MSFT add callback. In the current queued management add flow, hci_cmd_sync_work() still invokes mgmt_add_adv_patterns_monitor_complete() with the original pending command after msft_add_monitor_pattern() returns. The buggy scenario involves two paths, with each column showing the order within that path: MSFT add handling MGMT completion 1. insert monitor and handle 1. receive sync error 2. send MSFT add command 2. call add-monitor completion 3. callback sees bad response 3. load cmd->user_data 4. callback frees monitor 4. read monitor->handle Local MSFT setup failures have the other half of the same ownership bug: they return an error after the IDR insertion, but no later code removes the failed monitor from the IDR. Keep ownership with the pending management command until its completion. For normal management adds, the MSFT add callback now records successful controller state and returns errors to its caller. The management completion frees the monitor on non-success after copying the response handle, while resume/reregister callback-error cleanup remains in the MSFT callback. The success path keeps the existing bookkeeping. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 ? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x19f/0x330 ? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] kasan_report+0xe0/0x110 ? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] ? srso_alias_return_thunk+0x5/0xfbef5 ? 0xffffffffc00d00da ? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth] ? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth] ? hci_cmd_sync_work+0x1ab/0x210 [bluetooth] hci_cmd_sync_work+0x1c0/0x210 [bluetooth] ? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth] process_one_work+0x4fd/0xbc0 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_hci_cmd_sync_work+0x10/0x10 [bluetooth] ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 471 on cpu 3 at 285.205389s: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 __kasan_kmalloc+0xaa/0xb0 add_adv_patterns_monitor_rssi+0xd5/0x230 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] __sys_sendto+0x2bc/0x2d0 __x64_sys_sendto+0x76/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 454 on cpu 2 at 285.217112s: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 msft_add_monitor_sync+0x54a/0x570 [bluetooth] hci_add_adv_monitor+0x133/0x180 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Fixes: a2a4dedf88ab ("Bluetooth: advmon offload MSFT add monitor") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 32c48c7f6cc8c7888e46a8c81622154ccafda5d2 Author: Cen Zhang Date: Wed Jun 24 00:12:59 2026 +0800 Bluetooth: 6lowpan: hold L2CAP conn across debugfs control [ Upstream commit 518aa9505fa10ea5662349e5d2efd8c9e32a820b ] get_l2cap_conn() looks up an LE hci_conn under hdev protection, but then drops that protection before reading hcon->l2cap_data and before lowpan_control_write() later dereferences conn->hcon. A disconnect or device close can tear down the same L2CAP connection in that window. The buggy scenario involves two paths, with each column showing the order within that path: 6LoWPAN control write: HCI disconnect/device close: 1. get_l2cap_conn() finds hcon 1. hci_disconn_cfm() dispatches and hcon->l2cap_data. the L2CAP disconnect callback. 2. get_l2cap_conn() drops hdev 2. l2cap_conn_del() clears protection and returns conn. hcon->l2cap_data and drops the L2CAP connection reference. 3. lowpan_control_write() reads 3. hci_conn_del() removes and drops conn->hcon. the HCI connection. Take a reference to the L2CAP connection with l2cap_conn_hold_unless_zero() while hdev is still locked, and drop that reference after the debugfs command's last use of conn. This mirrors the existing L2CAP ACL receive-side handoff and keeps the connection dereferenceable after leaving hdev protection. Export the existing helper so the bluetooth_6lowpan module can use the same lifetime primitive. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in lowpan_control_write+0x374/0x520 The buggy address belongs to the object at ffff888111b9d000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes inside of freed 1024-byte region [ffff888111b9d000, ffff888111b9d400) Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 lowpan_control_write+0x374/0x520 (net/bluetooth/6lowpan.c:1131) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __debugfs_file_get+0xf7/0x400 full_proxy_write+0x9e/0xd0 vfs_write+0x1b0/0x810 ksys_write+0xd2/0x170 dnotify_flush+0x32/0x220 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 __kasan_kmalloc+0xaa/0xb0 l2cap_conn_add+0x45/0x520 l2cap_chan_connect+0xac6/0xd90 l2cap_sock_connect+0x216/0x350 __sys_connect+0x101/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 hci_conn_hash_flush+0xc0/0x140 hci_dev_close_sync+0x41a/0xb00 hci_dev_close+0x12f/0x160 hci_sock_ioctl+0x157/0x570 sock_do_ioctl+0xf7/0x210 sock_ioctl+0x32f/0x490 __x64_sys_ioctl+0xc7/0x110 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f kasan_record_aux_stack+0xa7/0xc0 insert_work+0x32/0x100 __queue_work+0x262/0xa60 queue_work_on+0xad/0xb0 l2cap_connect_cfm+0x4ef/0x670 hci_le_remote_feat_complete_evt+0x247/0x430 hci_event_packet+0x360/0x6f0 hci_rx_work+0x2ae/0x7a0 process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Fixes: 6b8d4a6a0314 ("Bluetooth: 6LoWPAN: Use connected oriented channel instead of fixed one") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit feb3fc2c38ed52003142f31e04109719b200c049 Author: Cen Zhang Date: Wed Jun 24 00:12:29 2026 +0800 Bluetooth: 6lowpan: avoid untracked enable work [ Upstream commit 352a59dc1f4a41314b6f827c17e16af7ca88271a ] lowpan_enable_set() allocates a temporary work item and schedules do_enable_set() on system_wq, then returns to debugfs. The debugfs active operation has ended at that point, but the worker still executes module text and manipulates enable_6lowpan and listen_chan. bt_6lowpan_exit() removes the debugfs files and immediately closes and puts listen_chan. It has no pointer to the queued work item, so it cannot cancel or flush it before tearing down the state that the worker uses. The buggy scenario involves two paths, with each column showing the order within that path: debugfs enable write module exit 1. lowpan_enable_set() allocates 1. bt_6lowpan_exit() removes set_enable work the debugfs file 2. schedule_work() queues 2. bt_6lowpan_exit() closes do_enable_set() and puts listen_chan 3. the write operation returns 3. module teardown can continue 4. do_enable_set() later runs against stale state Run the enable state transition synchronously in lowpan_enable_set() instead. The simple debugfs setter can sleep, and this file already handles the 6LoWPAN control write synchronously under the same set_lock. Once the setter returns, debugfs removal covers the whole operation and exit can no longer race with an untracked work item. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in do_enable_set+0x113/0x2e0 Workqueue: events do_enable_set [bluetooth_6lowpan] The buggy address belongs to the object at ffff888109cb8000 Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b601c031d4fa30b789cbdcc443a85dd992236324 Author: Suraj Kandpal Date: Wed Jul 1 14:45:03 2026 +0530 drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL [ Upstream commit e91da9053006da622b865e672a4a37439a3bb88b ] According to Bspec we only need to write SSC Enable PLL A bit and leave PLL B bit alone in PORT_CLOCK_CTL register. Bspec: 74667, 74492 Fixes: 3383ba2479f7 ("drm/i915/ltphy: Enable SSC during port clock programming") Signed-off-by: Suraj Kandpal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260701091503.1302226-3-suraj.kandpal@intel.com (cherry picked from commit 8e27f752037e72ccee9c4a7c4a6202ecf3daf603) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 0b98a503ed1ead044dfc81dc26c00cbe32f41dc7 Author: Bartosz Golaszewski Date: Tue Jun 30 16:28:16 2026 +0200 gpio: shared: make the voting mechanism adaptable [ Upstream commit b30973e8c3920ddfa9255a959b19057515b4e5e8 ] The current voting mechanism in GPIO shared proxy assumes that "low" is always the default value and users can only vote for driving the GPIO "high" in which case it will remain high as long as there's at least one user voting. This makes it impossible to use the automatic sharing management for certain use-cases such as the write-protect GPIOs of EEPROMs which are requested "high" and driven "low" to enable writing. In this case, if the WP GPIO is shared by multiple EEPROMs, and at least one of them wants to enable writing, the pin must be set to "low". Modify the voting heuristic to assume the value set by the first user on request to be the "default" and subseqent calls to gpiod_set_value() will constitute votes for a change of the value to the opposite. In the wp-gpios case it will mean that the nvmem core requests the GPIO as "out-high" for all EEPROMs sharing the pin, and when one of them wants to write, the pin will be driven low, enabling it. Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver") Reported-by: Marek Vasut Closes: https://lore.kernel.org/all/20260511163518.51104-1-marex@nabladev.com/ Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260630-gpio-shared-dynamic-voting-v3-1-8ecf0542953b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 8d12d1fede47a9001a682a61108e07a5dc482e3f Author: Steve French Date: Sun Jul 5 16:04:09 2026 -0500 smb: client: preserve leading slash for POSIX absolute symlink targets [ Upstream commit dce002f685e04e0c94e088cb66cb4021311cc6b5 ] When creating a native SMB symbolic link (CIFS_SYMLINK_TYPE_NATIVE) whose target is an absolute path on a mount that uses POSIX paths, the leading path separator was silently dropped from the stored symlink target. create_native_symlink() converted the target to UTF-16 with cifs_convert_path_to_utf16(). That helper was intended for share-relative SMB paths and therefore unconditionally strips a leading path separator. For an absolute POSIX symlink target the leading '/' is significant, so a target of "/foo/bar" was stored and read back as "foo/bar", even though the reparse point was still flagged as absolute (SYMLINK_FLAG_RELATIVE cleared). On a POSIX paths mount the symlink target is stored verbatim, so convert it directly with cifs_strndup_to_utf16() instead. This preserves the leading separator, avoids the leading-backslash stripping that cifs_convert_path_to_utf16() also performs (a backslash is a valid POSIX filename character), and uses NO_MAP_UNI_RSVD to match the readback path in smb2_parse_native_symlink(), which always converts the target with cifs_strndup_from_utf16() / NO_MAP_UNI_RSVD. This mirrors how the NFS and WSL reparse symlink creators convert their targets. The NT-style absolute symlink handling, which needs the "\??\" prefix and drive-letter colon preserved, continues to use cifs_convert_path_to_utf16() together with the existing masking of those bytes. Fixes: 12b466eb52d9 ("cifs: Fix creating and resolving absolute NT-style symlinks") Reviewed-by: Paulo Alcantara (Red Hat) Acked-by: Ralph Boehme Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a1f2ada2e4d33d316939dedefbfd2e7d94a0c61f Author: Namjae Jeon Date: Thu Jul 2 15:49:53 2026 +0900 ksmbd: fix multichannel binding and enforce channel limit [ Upstream commit 4b706360ffb7e459cb3d3edae30b06a584f6eddd ] A signed multichannel SESSION_SETUP binding request can require multiple authentication rounds. ksmbd excludes SESSION_SETUP from the signed request check and tries to sign every binding response with the channel signing key. The channel does not exist for STATUS_MORE_PROCESSING_REQUIRED, so that response is sent unsigned. Clients reject it with STATUS_ACCESS_DENIED. The final channel signing key also needs the key exported by the binding authentication context. Keep that key in the channel instead of overwriting the established session key, and use the session signing key for intermediate and failed binding responses. Retain the binding session reference until an error response has been signed and sent. Limit a session to 32 channels while holding the channel lock. Return STATUS_INSUFFICIENT_RESOURCES for an additional binding, matching the server limit expected by clients. This fixes smb2.multichannel.generic.num_channels, which previously failed the first binding with STATUS_ACCESS_DENIED and returned the same status instead of STATUS_INSUFFICIENT_RESOURCES for channel 33. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5a632f2f207e70e46c1b016d8d17bfd7d8ea1a8e Author: Eric Dumazet Date: Wed Jul 1 12:23:29 2026 +0000 amt: fix size calculation in amt_get_size() [ Upstream commit 9e05e91a9a847ed57926414bd7c2c5e54d6c56c6 ] amt_get_size() incorrectly used sizeof(struct iphdr) for the sizes of IFLA_AMT_DISCOVERY_IP, IFLA_AMT_REMOTE_IP, and IFLA_AMT_LOCAL_IP. These attributes contain IPv4 addresses (__be32), not full IP headers. Replace sizeof(struct iphdr) with sizeof(__be32) to avoid over-allocating netlink message space. Fixes: b9022b53adad ("amt: add control plane of amt interface") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260701122329.3562825-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ce5aa8084329351086894aa34d77e40301d5bd3d Author: Xiang Mei Date: Tue Jun 30 11:32:27 2026 -0700 net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket [ Upstream commit 9d160b35cc34a2ba8229d07651468a7848325135 ] smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done. Fixes: d7b0e37c1ac1 ("net/smc: restructure CDC message reception") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260630183227.2044998-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8e49cd891bda447c68122d672510a604a8bb6b24 Author: Jamal Hadi Salim Date: Wed Jul 1 12:19:12 2026 -0400 net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload [ Upstream commit 8b519cbcabe836a441369fbec1a8a6518a709251 ] There is a TOCTOU race condition in flower lockless approach between sizing a flow_rule buffer and filling it. zdi-disclosures@trendmicro.com reports: The cls_flower classifier operates with TCF_PROTO_OPS_DOIT_UNLOCKED (fl_change runs without RTNL), while RTM_NEWACTION holds RTNL, so the independent locking domains make the race reachable in practice. KASAN confirms: BUG: KASAN: slab-out-of-bounds in tcf_pedit_offload_act_setup+0x81b/0x930 Write of size 4 at addr ffff888001f27520 by task poc-toctou/312 The buggy address is located 0 bytes to the right of allocated 288-byte region [ffff888001f27400, ffff888001f27520) (cache kmalloc-512) Note: The result is a heap OOB write attacker-controlled content into the adjacent slab object (requires CAP_NET_ADMIN). The fix introduces reading tcfp_nkeys under act->tcfa_lock in all places using a new tcf_pedit_nkeys_locked() which replaces the old tcf_pedit_nkeys(). Additionally we close the remaining TOCTOU window between the sizing read and the fill reads by more careful accounting. Rather than silently truncating the key count, which leads to incorrect action semantics offloaded to hardware and secondary OOB writes if the remaining capacity is zero or consumed by prior actions, we enforce remaining capacity checks and return -ENOSPC if the required space exceeds the remaining capacity. Fixes: 71d0ed7079df ("net/act_pedit: Support using offset relative to the conventional network headers") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260701161912.125355-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 231a8a4b76cb1b1827b3b19d7b3603642f5aaaef Author: Xiang Mei Date: Tue Jun 30 10:41:09 2026 -0700 net: qualcomm: rmnet: validate MAP frame length before ingress parsing [ Upstream commit f0f1887a9e30712a1df03e152dce6fb91344b1f3 ] When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header. Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation") Reported-by: Weiming Shi Suggested-by: Subash Abhinov Kasiviswanathan Signed-off-by: Xiang Mei Reviewed-by: Subash Abhinov Kasiviswanathan Link: https://patch.msgid.link/20260630174110.2003121-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 982d6d6bc059c5dff37a2201c2f08c14bcfcbd20 Author: Shigeru Yoshida Date: Wed Jul 1 01:46:20 2026 +0900 qede: fix off-by-one in BD ring consumption on build_skb failure [ Upstream commit a0a558ca7e75b49e71f8c545c30e8c005e6e4e2f ] qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 ("qede: confirm skb is allocated before using") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation. Fixes: 8a8633978b84 ("qede: Add build_skb() support.") Signed-off-by: Shigeru Yoshida Reviewed-by: Jamie Bainbridge Link: https://patch.msgid.link/20260630164623.3152625-1-syoshida@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 952928564cc5fdb06f92d7e25c6cd2e1d816362b Author: Jens Emil Schulz Østergaard Date: Tue Jun 30 14:20:13 2026 +0200 net: microchip: vcap: fix races on the shared Super VCAP block [ Upstream commit d7a8d500d7e42837bd8dce40cb52c97c6e8706a9 ] The VCAP instances on a chip are not independent, yet they are locked independently. On sparx5 and lan969x the IS0 and IS2 instances are backed by the same Super VCAP hardware block and share its cache and command registers: every access drives the shared VCAP_SUPER_CTRL register and moves data through the shared cache registers. Accessing one instance therefore races with accessing another. The per-instance admin->lock cannot prevent this, as each instance takes a different lock. The locking issue is mostly disguised by the fact that the core usage of the vcap api runs under rtnl. However, the full rule dump in debugfs decodes rules straight from hardware (a READ command followed by a cache read) and runs outside rtnl, so it races a concurrent tc-flower rule write to another Super VCAP instance. Besides corrupting the dump, the read repopulates the shared cache between the writers cache fill and its write command, so the writer commits the wrong data and corrupts the hardware entry. Introduce vcap_lock() and vcap_unlock() helpers and route every rule lock site in the VCAP API and its debugfs code through them. Replace the per-instance admin->lock with a single mutex in struct vcap_control that serializes access to all instances. The helpers reach it through a new admin->vctrl back-pointer, and the clients initialise and destroy the control lock instead of a per-instance one. No path holds more than one instance lock, so collapsing them onto a single mutex cannot self-deadlock. Fixes: 71c9de995260 ("net: microchip: sparx5: Add VCAP locking to protect rules") Signed-off-by: Jens Emil Schulz Østergaard Link: https://patch.msgid.link/20260630-microchip_fix_vcap_locking-v1-1-f60a4596734d@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 815515ec68f527ca755cb1e2c1ff9148f6b3ea56 Author: Feng Liu Date: Tue Jun 30 14:51:51 2026 +0300 net/mlx5e: Fix publication race for priv->channel_stats[] [ Upstream commit 5a799714e8ca0bce9ea40694f49914cf1adbbaa9 ] mlx5e_channel_stats_alloc() publishes a new entry to priv->channel_stats[] and then increments priv->stats_nch as a publication token, but neither store carries any memory barrier: priv->channel_stats[ix] = kvzalloc_node(...); if (!priv->channel_stats[ix]) return -ENOMEM; priv->stats_nch++; Concurrent readers compute the loop bound from priv->stats_nch and then dereference priv->channel_stats[i] using plain accesses, e.g. for (i = 0; i < priv->stats_nch; i++) { struct mlx5e_channel_stats *cs = priv->channel_stats[i]; ... cs->rq.packets ... } On weakly-ordered architectures (ARM, PowerPC, RISC-V) the writes to channel_stats[ix] and stats_nch may become visible to other CPUs out of program order. A reader can observe stats_nch == N while still seeing channel_stats[N-1] == NULL, leading to a NULL pointer dereference in the channel_stats loop. This has been observed in production on BlueField-3 DPUs (arm64), where ovs-vswitchd queries netdev statistics over netlink during NIC bringup, racing mlx5e_open_channel() -> mlx5e_channel_stats_alloc() on another CPU: Unable to handle kernel NULL pointer dereference at virtual address 0x840 Hardware name: BlueField-3 DPU pc : mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core] Call trace: mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core] dev_get_stats+0x50/0xc0 ovs_vport_get_stats+0x38/0xac [openvswitch] ovs_vport_cmd_fill_info+0x194/0x290 [openvswitch] ovs_vport_cmd_get+0xbc/0x10c [openvswitch] genl_family_rcv_msg_doit+0xd0/0x160 genl_rcv_msg+0xec/0x1f0 netlink_rcv_skb+0x64/0x130 genl_rcv+0x40/0x60 netlink_unicast+0x2fc/0x370 netlink_sendmsg+0x1dc/0x454 ... __arm64_sys_sendmsg+0x2c/0x40 Add mlx5e_stats_nch_write() and mlx5e_stats_nch_read() helpers in en.h that wrap the smp_store_release()/smp_load_acquire() pair on stats_nch. The release/acquire pair establishes the contract: stats_nch == N => channel_stats[0..N-1] are visible and non-NULL. Publish the stats_nch increment via mlx5e_stats_nch_write() in the writer (mlx5e_channel_stats_alloc()), and read stats_nch via mlx5e_stats_nch_read() in all readers: mlx5e RX/TX queue stats, mlx5e_get_base_stats(), ethtool channels stats, IPoIB stats, the sw_stats fold and the HV VHCA stats agent. Fixes: fa691d0c9c08 ("net/mlx5e: Allocate per-channel stats dynamically at first usage") Signed-off-by: Feng Liu Reviewed-by: Eran Ben Elisha Reviewed-by: Cosmin Ratiu Reviewed-by: Nimrod Oren Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630115151.729219-4-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f5677797b094c3ec5fb350eb8ea7710b88a3d018 Author: Feng Liu Date: Tue Jun 30 14:51:50 2026 +0300 net/mlx5e: Fix HV VHCA stats agent registration race [ Upstream commit 89b25b5f46f488ea3b29b3444864c76944c9075b ] mlx5e_hv_vhca_stats_create() registers the stats agent through mlx5_hv_vhca_agent_create(). The helper publishes the agent in hv_vhca->agents[type] under agents_lock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e. The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5e_hv_vhca_stats_control(). That callback may either: - call cancel_delayed_work_sync(&priv->stats_agent.work), or - call queue_delayed_work(priv->wq, &sagent->work, sagent->delay). However, the delayed_work and priv->stats_agent.agent are only initialized after mlx5_hv_vhca_agent_create() returns to mlx5e: agent = mlx5_hv_vhca_agent_create(...); /* publish + invalidate */ ... priv->stats_agent.agent = agent; /* too late */ INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */ If the asynchronous control path runs before the two assignments above, it can: - Operate on an uninitialized delayed_work whose timer.function is NULL. queue_delayed_work() calls add_timer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer. - Re-initialize the timer later through INIT_DELAYED_WORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry). - When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads sagent->agent (NULL) and dereferences it inside mlx5_hv_vhca_agent_write(). Fix this by: - Initializing priv->stats_agent.work before invoking mlx5_hv_vhca_agent_create(), so the work is always in a valid state when the control callback observes it. - Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter to mlx5_hv_vhca_agent_create(). The helper writes the agent pointer to *ctx_update before publishing into hv_vhca->agents[] and triggering the agents_update flow, so any callback subsequently invoked from that flow already sees a valid priv->stats_agent.agent. This avoids having the control callback participate in agent initialization. While at it, access priv->stats_agent.agent with READ_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and clear priv->stats_agent.buf on the agent_create() failure path. Fixes: cef35af34d6d ("net/mlx5e: Add mlx5e HV VHCA stats agent") Signed-off-by: Feng Liu Reviewed-by: Eran Ben Elisha Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630115151.729219-3-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit abc4c56427f144c96b2827a4db3b90eb5b7349a2 Author: Feng Liu Date: Tue Jun 30 14:51:49 2026 +0300 net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation [ Upstream commit 25f6b929c7e379cbea7cb8caa67b49b2d1efae17 ] mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(), before mlx5e_open(). At that point priv->stats_nch is still zero, because it is only ever incremented in mlx5e_channel_stats_alloc(), which is reached only from mlx5e_open_channel(). mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and kvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16) rather than NULL. The "if (!buf)" guard does not catch this, and mlx5e_hv_vhca_stats_create() completes "successfully" with priv->stats_agent.buf set to ZERO_SIZE_PTR. Once channels are opened (priv->stats_nch > 0) and the hypervisor enables stats reporting, mlx5e_hv_vhca_stats_work() recomputes buf_len using the new non-zero stats_nch and calls memset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at address 0x10. Allocate the buffer based on priv->max_nch, which is set in mlx5e_priv_init() and is the upper bound on stats_nch: - Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that returns sizeof(per_ring_stats) * max(max_nch, stats_nch), and use it for the kvzalloc() in mlx5e_hv_vhca_stats_create(). - Keep mlx5e_hv_vhca_stats_buf_size() (which returns based on stats_nch) for the worker's active payload size, so the wire format (block->rings = stats_nch) and the amount of data filled by mlx5e_hv_vhca_fill_stats() are unchanged. The max(max_nch, stats_nch) guard handles the rare case where mlx5e_attach_netdev() recomputes max_nch downward across a detach/resume cycle while priv->stats_nch persists (mlx5e_detach_netdev does not call mlx5e_priv_cleanup, so stats_nch is only reset when the netdev is destroyed). Without the guard, the worker could compute buf_len from stats_nch and overrun the smaller buffer allocated based on the reduced max_nch. Allocating a non-zero buffer also makes the kvzalloc() failure path in mlx5e_hv_vhca_stats_create() reachable for the first time: it returns early without (re)creating the agent. Clear priv->stats_agent.{agent,buf} in mlx5e_hv_vhca_stats_destroy() after freeing them, so that if a later create() bails out on this path, a subsequent teardown does not double-free the stale agent/buffer left from a previous enable/disable cycle. This mirrors the existing mlx5e pattern of preallocating arrays of size max_nch (e.g. priv->channel_stats) and lazily populating entries up to stats_nch on demand. Fixes: fa691d0c9c08 ("net/mlx5e: Allocate per-channel stats dynamically at first usage") Signed-off-by: Feng Liu Reviewed-by: Eran Ben Elisha Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630115151.729219-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 98fc2deffcf1949fbb14c710f21b4db362c8ec4b Author: Damon Ding Date: Tue Jun 23 10:35:06 2026 +0800 drm/bridge: analogix_dp: Fix PE/VS value shift mismatch during link training [ Upstream commit 6bb8898f702385d363dc2c513a1efa62807f8068 ] VS/PE values returned by drm_dp_get_adjust_request_voltage() and drm_dp_get_adjust_request_pre_emphasis() are already encoded to their native DPCD register bit positions. However, DPCD_VOLTAGE_SWING_SET / DPCD_PRE_EMPHASIS_SET macros perform an extra internal shift. Feeding the raw offset-bearing values directly leads to overlapping bitfields and invalid lane training configuration, causing link training failures and black screen. Add right shift using DP_TRAIN_*_SHIFT constants to strip the DPCD bit offsets before passing values to the SET macros and subsequent checks. Apply this fix for both clock recovery and adjust training code paths. Reported-by: Vicente Bergas Closes: https://lore.kernel.org/all/CAAMcf8D-d+5n=H44KeKBSqWY42m+o32W+mO-r15VqWNyYhJL7Q@mail.gmail.com/ Fixes: d84b087c7662 ("drm/bridge: analogix_dp: Apply DP helper APIs to get adjusted voltages and pre-emphasises") Signed-off-by: Damon Ding Link: https://lore.kernel.org/all/CAAMcf8D-d+5n=H44KeKBSqWY42m+o32W+mO-r15VqWNyYhJL7Q@mail.gmail.com/ Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260623023506.309858-1-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit 5a95aa0198af75047d98fb72950642c89dab770f Author: Shay Drory Date: Tue Jun 30 14:29:17 2026 +0300 net/mlx5e: TC, skip peer flow cleanup when LAG seq is unavailable [ Upstream commit 7bed4af0ced82948d660205efecd551ef8bc3912 ] mlx5_lag_get_dev_seq() will return error when the peer isn't in the LAG or when no device is marked as master. Result bad memory access and kernel crash[1]. Hence, skip the peer when lookup fails. Note: In case there are peer flows, they are cleaned before LAG cleared the master mark. [1] RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0x3d/0x350 [mlx5_core] Call Trace: mlx5e_tc_clean_fdb_peer_flows+0xc1/0x130 [mlx5_core] mlx5_esw_offloads_unpair+0x3a/0x400 [mlx5_core] mlx5_esw_offloads_devcom_event+0xee/0x360 [mlx5_core] mlx5_devcom_send_event+0x7a/0x140 [mlx5_core] mlx5_esw_offloads_devcom_cleanup+0x2f/0x90 [mlx5_core] mlx5e_tc_esw_cleanup+0x28/0xf0 [mlx5_core] mlx5e_rep_tc_cleanup+0x19/0x30 [mlx5_core] mlx5e_cleanup_uplink_rep_tx+0x36/0x40 [mlx5_core] mlx5e_cleanup_rep_tx+0x55/0x60 [mlx5_core] mlx5e_detach_netdev+0x96/0xf0 [mlx5_core] mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core] mlx5e_vport_rep_unload+0xdd/0x110 [mlx5_core] __esw_offloads_unload_rep+0x81/0xb0 [mlx5_core] mlx5_eswitch_unregister_vport_reps+0x1d7/0x220 [mlx5_core] mlx5e_rep_remove+0x22/0x30 [mlx5_core] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xe8/0x1b0 device_del+0x159/0x3c0 mlx5_rescan_drivers_locked+0xbc/0x2d0 [mlx5_core] mlx5_unregister_device+0x54/0x80 [mlx5_core] mlx5_uninit_one+0x73/0x130 [mlx5_core] remove_one+0x78/0xe0 [mlx5_core] pci_device_remove+0x39/0xa0 Fixes: 971b28accc09 ("net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630112917.698313-4-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4d720c6c60e1852253b68aeee3044ebed5243adb Author: Shay Drory Date: Tue Jun 30 14:29:16 2026 +0300 net/mlx5: LAG, MPESW, Fix missing complete() on devcom error [ Upstream commit d4b85f9a668b9c44216bb78daf4ec1a915cc92d1 ] mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken. Fixes: b430c1b4f63b ("net/mlx5: Replace global mlx5_intf_lock with HCA devcom component lock") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630112917.698313-3-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 40cc06bf71476932e5d139fa326dcd0372766e16 Author: Shay Drory Date: Tue Jun 30 14:29:15 2026 +0300 net/mlx5: LAG, Fix off-by-one in single-FDB error rollback [ Upstream commit 0f0e4ae6975c773f7854fc48932a267f6c79088f ] On failure at index i, the reverse cleanup loop in mlx5_lag_create_single_fdb() starts from i, so the failed index itself is rolled back. That can operate on uninitialized state or double-tear-down a rule the add_one path already self-rolled-back. Start the rollback from i - 1 so only successfully-installed entries are undone. Fixes: ddbb5ddc43ad ("net/mlx5: LAG, Refactor lag logic") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260630112917.698313-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fd2ef924a56fb70fef26a6f0271a086787125c97 Author: Shay Drory Date: Sun May 31 14:39:46 2026 +0300 net/mlx5: LAG, extend shared FDB API with group_id filter [ Upstream commit 3cbce590b7f2e9f056ed803a05f9ee09ac4a49a7 ] Add a group_id parameter to mlx5_lag_shared_fdb_create() and mlx5_lag_shared_fdb_destroy() to scope shared FDB operations to a specific SD group. When group_id is U32_MAX, the functions operate on all LAG devices. When group_id is non-zero, they operate only on devices in that SD group without issuing FW LAG commands, since SD LAG is a pure software construct. Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260531113954.395443-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit d14f2dbf727c004f120c04204b0c60e7cf23ebd4 Author: Shay Drory Date: Sun May 31 14:39:45 2026 +0300 net/mlx5: LAG, prepare for SD device integration [ Upstream commit 14a47f55c8def9d677a4307bdce88b40255e8505 ] Socket Direct (SD) secondaries devices will participate in LAG, even though they are silent. SD secondary devices share the same physical port as their primary but are separate PCI functions that need to be tracked alongside regular LAG ports. Extend lag_func with a group_id field to identify SD group membership and introduce a unified iterator that can filter by group. Add APIs for registering SD secondary devices in an existing LAG. Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260531113954.395443-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit 5092213b9a31ecfb64e6534fe74137e646c6779b Author: Shay Drory Date: Sun May 31 14:39:44 2026 +0300 net/mlx5: LAG, replace peer count check with direct peer lookup [ Upstream commit 2ca494dad9676301ecde1c9e214bfbf83d4c6326 ] Replace mlx5_eswitch_get_npeers() count-based check with a new mlx5_eswitch_is_peer() function that directly verifies the peer relationship between two eswitches. This change prepares for SD LAG support, which is a virtual LAG that does not have num_lag_ports capability and cannot use the count-based peer validation. Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260531113954.395443-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit 3b8b364f97f40420498e3519adea155096cc4f65 Author: Shay Drory Date: Sun May 31 14:39:41 2026 +0300 net/mlx5: LAG, factor out shared FDB code into dedicated file [ Upstream commit cf6c4c0508a9a3858203b726bd3a3f9557449f67 ] Refactor shared FDB LAG logic into a new lag/shared_fdb.c file to improve code organization and enable reuse. Move shared FDB specific functions from lag.c and introduce consolidated APIs: - mlx5_lag_shared_fdb_create() handles LAG activation with shared FDB - mlx5_lag_shared_fdb_destroy() handles LAG deactivation with shared FDB Update mlx5_do_bond(), mlx5_disable_lag() and mpesw.c to use the new APIs, which simplifies the shared FDB code paths. Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260531113954.395443-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit 7ac37a167cc69ea1ba6efdaf6ddad3849aa3e0be Author: Mark Bloch Date: Sun May 3 23:27:23 2026 +0300 net/mlx5: Lag, avoid LAG and representor lock cycles [ Upstream commit 63ec6c69e6134ce4cf5dc9acc61b49bac4916979 ] The LAG shared-FDB and multiport E-Switch transitions rescan auxiliary devices and reload IB representors while holding ldev->lock. Driver bind/unbind paths may register or unregister E-Switch representor ops, and representor load paths may enter LAG code, so holding ldev->lock across those calls creates lock-order cycles with the E-Switch representor lock. Keep the devcom component locked for the transition, but drop ldev->lock before rescanning auxiliary devices or reloading IB representors. Mark the LAG transition as in progress while the lock is dropped and assert the devcom lock where the helper relies on it. This preserves LAG serialization while avoiding ldev->lock nesting under E-Switch representor registration. Signed-off-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260503202726.266415-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit db9e44e0ed63cc906067b939ab3fd6325a0bc6f7 Author: Mark Bloch Date: Sun May 3 23:27:22 2026 +0300 net/mlx5: E-Switch, add representor lifecycle lock [ Upstream commit 9b8468f001e46c4ffcbbeb2050aabf80e1ed7960 ] Add a per-E-Switch mutex for serializing representor lifecycle work and provide small helpers for taking and dropping it. Initialize and destroy the mutex with the E-Switch offloads state. Add the lock and helper API first. Follow-up patches will take the lock in the individual representor lifecycle components. This keeps the functional changes split by component and leaves this patch without intended behavior change, making the series easier to review and bisectable. Signed-off-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260503202726.266415-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit 25d4c094830062d0b3889648e6d8f24fa55805ab Author: Mark Bloch Date: Sun May 3 23:27:20 2026 +0300 net/mlx5: Lag: refactor representor reload handling [ Upstream commit b501400fa66d9b8045f282ae8de80ceb6e02fe85 ] Representor reload during LAG/MPESW transitions has to be repeated in several flows, and each open-coded loop was easy to get out of sync when adding new flags or tweaking error handling. Move the sequencing into a single helper so that all call sites share the same ordering and checks. Signed-off-by: Mark Bloch Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260503202726.266415-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f0e4ae6975c ("net/mlx5: LAG, Fix off-by-one in single-FDB error rollback") Signed-off-by: Sasha Levin commit 6f2cb20d8e286218d51754f06ee219d8ce754b18 Author: Mingyou Chen Date: Wed Jul 1 20:01:39 2026 +0800 platform/x86: bitland-mifs-wmi: Fix NULL pointer dereference during suspend/resume [ Upstream commit d3666875c75eb1bc8090343fa0d6fc8fb7924356 ] The driver registers two distinct WMI devices: a control device (BITLAND_WMI_CONTROL) and an event device (BITLAND_WMI_EVENT). During the probe phase, the event device handling path returns early before initializing the platform profile device (data->pp_dev), leaving it NULL. However, the PM sleep operations are registered globally for the WMI driver and are triggered for both devices. When entering suspend, the event device invokes bitland_mifs_wmi_suspend(), which passes the uninitialized data->pp_dev (NULL) into laptop_profile_get(). This leads to a NULL pointer dereference inside dev_get_drvdata(), causing a kernel Oops and halting the suspend sequence. Fix this by adding a validity check for data->pp_dev in both the suspend and resume callbacks, safely skipping profile operations for the event device. Fixes: dc1ec4fa86b2 ("platform/x86: bitland-mifs-wmi: Add new Bitland MIFS WMI driver") Reviewed-by: Armin Wolf Signed-off-by: Mingyou Chen Reviewed-by: Armin Wolf Link: https://patch.msgid.link/20260701120140.430659-1-qby140326@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 230173cc6105bdfb2696d37e6e56687b003fbe63 Author: Wyatt Feng Date: Fri Jul 3 13:04:46 2026 +0800 netfilter: xt_connmark: reject invalid shift parameters [ Upstream commit 1b47026fb4b35bac850ad6e8a4ad7fc018e09ebc ] Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path. Fixes: 472a73e00757 ("netfilter: xt_conntrack: Support bit-shifting for CONNMARK & MARK targets.") Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Reviewed-by: Ren Wei Reviewed-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 94427ca359435104a8d94fc583cc93e99002ec96 Author: Pablo Neira Ayuso Date: Thu Jul 2 14:33:09 2026 +0200 netfilter: nft_set_rbtree: get command skips end element with open interval [ Upstream commit d63611cbe8af99dd61b118ee6e5b5e3e518250b2 ] The get command on intervals provide partial matches such as subranges for usability reasons. However, an open interval has no closing end element. If the closing element matches within the range of the open internal, ie. its closest match is the start element of the open range, then, return 0 but offer no matching element to userspace through netlink as a special case. Userspace provides at least a matching start element in this case and the closing end element matching the open interal is ignored. Another possibility is to report the matching start element of the open interval for this end interval. However, this results in duplicated matching being listed in userspace because userspace does not expect a start element as response to a end element. Fixes: 2aa34191f06f ("netfilter: nft_set_rbtree: use binary search array in get command") Reported-by: Melbin K Mathew Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit d5e39e5eb6b30bc4a3bb7aba54c293cf36a806c7 Author: Zhixing Chen Date: Wed Jul 1 18:09:30 2026 +0800 netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop [ Upstream commit 43ccc20b5a733226417832cf16ef45322e594990 ] The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zhixing Chen Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 905a927b2e6fec7b174e9e5644d271047b61378f Author: Feng Wu Date: Thu Jun 25 08:44:25 2026 +0000 netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() [ Upstream commit 444853cd438201007da5359821adcc2995655ab1 ] On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64. Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators") Signed-off-by: Feng Wu Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 00d034fe8230dfc5832fe011ff2d81c1a2cc7a29 Author: Wyatt Feng Date: Sun Jun 28 16:05:54 2026 +0800 netfilter: xt_u32: reject invalid shift counts [ Upstream commit 64cdf7d30ac18e43df6c48004435febb965809a8 ] u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path. Fixes: 1b50b8a371e9 ("[NETFILTER]: Add u32 match") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f618cbe9b24cd0202004d2db781d5f80ab77037f Author: Qihang Date: Wed Jul 1 10:26:17 2026 +0800 gue: validate REMCSUM private option length [ Upstream commit d335dcc6f521571d57117b8deeebc940836e5450 ] GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation. Fixes: c1aa8347e73e ("gue: Protocol constants for remote checksum offload") Signed-off-by: Qihang Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ea866cab12db1a2100b400a8b03569e5bc0ee29a Author: Xiang Mei Date: Mon Jun 29 21:51:21 2026 -0700 net: usb: net1080: validate packet_len before pad-byte access in rx_fixup [ Upstream commit 03f384bc0cb8d4a1301d4f5b0baef2d980258383 ] For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading. Fixes: 904813cd8a0b ("[PATCH] USB: usbnet (4/9) module for net1080 cables") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260630045121.1565324-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9d343a4889e5f5a1ec216d8b7d3f04ae1bc6160d Author: Jia He Date: Tue Jun 30 22:23:47 2026 +0000 arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1 [ Upstream commit 6666336d8fe5f3f0cd3f8da2865ca78110a6e170 ] Commit 93d7356e4b30 ("arm64: sysreg: Describe ID_AA64DFR2_EL1 fields") encodes the FEAT_BWE2 value of the BWE field as '0b0002'. Binary literals only accept the digits 0 and 1, so the intended value is 2, i.e. 0b0010. The macro generated by gen-sysreg.awk currently expands to #define ID_AA64DFR2_EL1_BWE_FEAT_BWE2 UL(0b0002) is not legal C and would fail to compile if any in-tree code referenced it. At present no caller uses this enum value, so the kernel still builds cleanly, but the bug is latent. Fix the typo by using the correct binary literal 0b0010. Cc: Bin Guo Fixes: 93d7356e4b30 ("arm64: sysreg: Describe ID_AA64DFR2_EL1 fields") Signed-off-by: Jia He Reviewed-by: Mark Brown Reviewed-by: Oliver Upton Acked-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 79b33d9f1d9c1793daadfb9ba281b669f81b73de Author: Yiyang Chen Date: Tue Jun 23 06:23:15 2026 +0000 selftests/hid: Cover hid_bpf_get_data() size overflow [ Upstream commit eebbef7c468a5cb58c4772849ee5066441166cf0 ] Add a HID-BPF regression check for hid_bpf_get_data() requests whose size would overflow when added to the offset. The new rdesc fixup callback asks for offset 2 and size ~0ULL, then records whether the helper returns NULL. A vulnerable kernel returns a non-NULL pointer because the runtime check wraps the addition. A fixed kernel rejects the request. The callback records the helper result without dereferencing any returned pointer. The callback reports the helper result through BSS and returns 0 intentionally. hid_rdesc_fixup return values are consumed as report descriptor fixup results, so a positive test-result value would be interpreted as a replacement report descriptor size. Also add KHDR_INCLUDES to the HID selftest build so hid_bpf.c sees the current kernel UAPI HID definitions on systems whose installed headers do not provide enum hid_report_type. Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs") Signed-off-by: Yiyang Chen Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit b56f874e49e64f09ceb51e9473432d8c9e977042 Author: Yiyang Chen Date: Tue Jun 23 06:23:14 2026 +0000 selftests/hid: Load only requested struct_ops maps [ Upstream commit 5aad55011a37d999cf99d14bafb6a093a1a70466 ] The HID selftest skeleton contains several struct_ops maps, but each test usually wants to load only the programs named by that test. load_programs() disabled auto-attach for all maps, but left struct_ops autocreate enabled. libbpf can enable autoload for programs referenced by autocreated struct_ops maps, so an unrelated program can be loaded and fail even when the current test does not use it. Disable autocreate for all struct_ops maps by default, then re-enable it only for the maps selected by the test before loading the skeleton. Signed-off-by: Yiyang Chen Fixes: f64c1a459339 ("selftests/hid: disable struct_ops auto-attach") Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit f81bc5a709dcbaf2a3bbef4ca7167f93900cc39f Author: Yiyang Chen Date: Tue Jun 23 06:23:13 2026 +0000 HID: bpf: Fix hid_bpf_get_data() range check [ Upstream commit 2d044049421dd48212b28646a850749d4a2d57fa ] hid_bpf_get_data() returns a pointer into the HID-BPF context data when the caller-provided offset and size fit inside ctx->allocated_size. The current check adds rdwr_buf_size and offset before comparing the result against ctx->allocated_size. Since both values are unsigned, a very large size can wrap the sum below ctx->allocated_size and make the helper return a pointer even though the requested range is not contained in the backing buffer. Use check_add_overflow() to reject wrapped range ends before comparing the requested range end against ctx->allocated_size. Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs") Signed-off-by: Yiyang Chen Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 3dd3e43f17cda174009a51fe668046ed7afef46a Author: Cen Zhang Date: Sat Jun 27 12:27:58 2026 +0800 ntfs: avoid stale runlist element dereference in fallocate [ Upstream commit 88496c4ac5a6ade75619f4b1015706a8b924d50a ] ntfs_attr_fallocate() allocates holes and delayed allocations inside initialized size by looking up the current runlist element under ni->runlist.lock. The returned struct runlist_element is only a borrowed pointer into ni->runlist.rl. A writer can replace and free that array after the read lock is dropped, so later reads of rl->lcn, rl->length and rl->vcn can touch freed memory. The buggy scenario involves two paths, with each column showing the order within that path: ntfs_attr_fallocate(): 1. Take ni->runlist.lock for read. 2. Get rl from ntfs_attr_find_vcn_nolock(). 3. Drop ni->runlist.lock. 4. Read rl->lcn, rl->length and rl->vcn. mmap page_mkwrite: 1. Enter ntfs_filemap_page_mkwrite(). 2. Reach __ntfs_write_iomap_begin() and ntfs_attr_map_cluster(). 3. Merge allocation state with ntfs_runlists_merge(). 4. Reallocate ni->runlist.rl in ntfs_rl_realloc(), freeing the old array. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in ntfs_attr_fallocate+0xbb8/0xd00 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? ntfs_attr_fallocate+0xbb8/0xd00 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? ntfs_attr_fallocate+0xbb8/0xd00 kasan_report+0xe0/0x110 ? ntfs_attr_fallocate+0xbb8/0xd00 ntfs_attr_fallocate+0xbb8/0xd00 ? lock_acquire+0x2b8/0x2f0 ? __pfx_ntfs_attr_fallocate+0x10/0x10 ? 0xffffffffc0000095 ? down_write+0x10d/0x1e0 ntfs_fallocate+0x5c9/0x1d00 ? __pfx_ntfs_fallocate+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x2b8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? selinux_file_permission+0x3a7/0x510 vfs_fallocate+0x29d/0xd30 __x64_sys_fallocate+0xc7/0x150 ? do_syscall_64+0x81/0x6a0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 410: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kvmalloc_node_noprof+0x353/0x920 ntfs_rl_realloc+0x3f/0x110 ntfs_runlists_merge+0xaa3/0x3010 ntfs_attr_map_cluster+0x4e5/0xf80 ntfs_attr_fallocate+0x53f/0xd00 ntfs_fallocate+0x5c9/0x1d00 vfs_fallocate+0x29d/0xd30 __x64_sys_fallocate+0xc7/0x150 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 424: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x307/0x580 ntfs_rl_realloc+0x6f/0x110 ntfs_runlists_merge+0x7b1/0x3010 ntfs_attr_map_cluster+0x4e5/0xf80 __ntfs_write_iomap_begin+0x8cd/0x2280 iomap_iter+0x6de/0x11e0 iomap_page_mkwrite+0x391/0x650 ntfs_filemap_page_mkwrite+0x1ac/0x400 do_page_mkwrite+0x15c/0x280 __handle_mm_fault+0xd6d/0x1ca0 handle_mm_fault+0x19c/0x470 do_user_addr_fault+0x23b/0x9c0 exc_page_fault+0x5c/0xc0 asm_exc_page_fault+0x26/0x30 Fix this by copying the needed runlist fields while the read lock is still held and using only those scalar snapshots after unlocking. After the snapshot, ntfs_attr_map_cluster() can also find that the range is already mapped and return balloc=false. Only call ntfs_dio_zero_range() when new clusters were allocated, matching the write iomap path and preserving the zero-newly-allocated-holes behavior. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6706e332151b7f3eba474691088c47af2a820089 Author: Ariana Lazar Date: Thu Jun 4 16:46:47 2026 +0300 iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1 case [ Upstream commit e74c0d0eef7e1fa9fd387b81b2787b4581e0b11c ] Ensure that if a device has Vref1 but reading the regulator returns an error, mcp47feb02_init_ctrl_regs() is not called with an uninitialized vref1_uV value. Also add a device_property_present() check for the Vref1 supply before reading the regulator. Fixes: dd154646d292 ("iio: dac: mcp47feb02: Fix Vref validation [1-999] case") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/adiPnla0M5EzvgD-@stanley.mountain/ Signed-off-by: Ariana Lazar Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9a1479b05bd9ee1c888f0f349ae6aabc9c0f3f70 Author: Anshuman Khandual Date: Fri Jun 26 02:28:45 2026 +0100 arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range() [ Upstream commit ff4c5a0de1f2ef7737a8688a86e19301e567020d ] Commit 48478b9f7913 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range") inadvertently introduced redundant TLB invalidation when clearing a block entry, resulting in unnecessary broadcast invalidation on CPUs without support for range-based invalidation. Re-introduce the old behaviour, along with some expanded comments to help people working in this area next time around. Cc: Catalin Marinas Cc: Will Deacon Cc: Ryan Roberts Cc: David Hildenbrand Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Reported-by: Ben Hutchings Closes: https://lore.kernel.org/all/b0d5836032ce3135bfc473f6bff791306d086925.camel@decadent.org.uk/ Fixes: 48478b9f7913 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()") Signed-off-by: Anshuman Khandual Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Catalin Marinas [will: Reword comments and commit message] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 67a863ceb348923936f4819dcbd62dc0f604a766 Author: Catalin Marinas Date: Wed Jun 10 11:37:16 2026 +0100 arm64: Avoid eager DVMSync reclaim batches with C1-Pro SME erratum [ Upstream commit 534eb6940a89ff7ca3f2ab6582f3548ca97674c3 ] The C1-Pro SME DVMSync workaround currently samples mm_cpumask() from arch_tlbbatch_add_pending(). It requires a DSB after every batched TLBI so that the mask read is ordered after the hardware DVMSync, defeating much of the reclaim batching benefit. Introduce the sme_active_cpus mask tracking which CPUs run in user-space with SME enabled and use it for batch flushing instead of accumulating the mm_cpumask() of the unmapped pages. Fixes: 0baba94a9779 ("arm64: errata: Work around early CME DVMSync acknowledgement") Signed-off-by: Catalin Marinas Cc: Will Deacon Tested-by: Joshua Liu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f7e8117e42b20c30d2a5edab82c944a5e381d791 Author: Lee Jones Date: Tue Jun 16 11:26:56 2026 +0000 HID: core: Fix OOB read in hid_get_report for numbered reports [ Upstream commit af1a9b65ebe8a948eda805c14b78d4d0767cb1b5 ] When a caller passes a size of 0 to hid_report_raw_event() for a numbered report, the function originally called hid_get_report() before performing any size validation. Inside hid_get_report(), if the report is numbered (report_enum->numbered is true), it unconditionally dereferences data[0] to extract the report ID. With a size of 0, this results in an out-of-bounds read or kernel panic. Fix this by moving the numbered report size validation check before the call to hid_get_report(), ensuring that size is at least 1 before dereferencing the data pointer. Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event") Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ef649703dce0df1364fcec3cdad9b32d1c522939 Author: Georgiy Osokin Date: Sun May 17 15:06:39 2026 +0300 HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait() [ Upstream commit 0021eb09041f021c079be1022934a280f7f176c0 ] In picolcd_send_and_wait(), an integer overflow of the signed loop counter 'k' can theoretically lead to a NULL pointer dereference of 'raw_data'. If the loop executes more than INT_MAX times, 'k' becomes negative, making the condition 'k < size' true even when 'size' is 0. Change the type of 'k' to 'unsigned int' to prevent the overflow and eliminate the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. [jkosina@suse.com: extended hash length] Fixes: fabdbf2fd22fa17 ("HID: picoLCD: split driver code") Signed-off-by: Georgiy Osokin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9a2e36963a3fc52401586657d34e3f1c5a01ea56 Author: Cen Zhang Date: Thu Jun 25 12:45:47 2026 +0800 ntfs: avoid stale runlist element dereference in MFT writeback [ Upstream commit 81fe702ff1760da32bcd3ef4494b2a33dbeced72 ] ntfs_write_mft_block() maps each $MFT record through the $MFT data runlist. For sub-folio clusters it looks up a struct runlist_element under ni->runlist.lock, drops the lock, and later uses rl->length and rl->vcn when choosing folio_sz. That pointer is only borrowed from ni->runlist.rl. Concurrent $MFT allocation extension can merge a replacement runlist under the same lock, and ntfs_rl_realloc() can free the old backing array. If that happens between the lookup and the later folio_sz decision, writeback can dereference freed runlist storage. The buggy scenario involves two paths, with each column showing the order within that path: MFT writeback path: $MFT allocation extension: 1. Look up rl under 1. Extend the $MFT data allocation. ni->runlist.lock. 2. Publish a replacement runlist. 2. Drop ni->runlist.lock. 3. Free the old runlist array. 3. Read rl->length and rl->vcn to choose folio_sz. Compute the remaining run length while ni->runlist.lock is still held, and use that scalar after unlock. This preserves the existing folio sizing decision without carrying a borrowed runlist_element across the lock boundary. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in ntfs_mft_writepages+0x1c8d/0x1fb0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? ntfs_mft_writepages+0x1c8d/0x1fb0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? ntfs_mft_writepages+0x1c8d/0x1fb0 kasan_report+0xe0/0x110 ? ntfs_mft_writepages+0x1c8d/0x1fb0 ntfs_mft_writepages+0x1c8d/0x1fb0 ? __pfx_ntfs_mft_writepages+0x10/0x10 ? __pfx___mutex_unlock_slowpath+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? iput+0x92/0xa80 do_writepages+0x219/0x530 ? __pfx_do_writepages+0x10/0x10 __writeback_single_inode+0x117/0xf50 ? do_raw_spin_lock+0x130/0x270 ? __pfx_do_raw_spin_lock+0x10/0x10 ? __pfx___writeback_single_inode+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 writeback_sb_inodes+0x65b/0x1810 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x2b8/0x2f0 ? __pfx_writeback_sb_inodes+0x10/0x10 ? lock_release+0x1e0/0x280 ? _raw_spin_unlock+0x23/0x40 ? move_expired_inodes+0x2b8/0x850 __writeback_inodes_wb+0xf4/0x270 ? __pfx___writeback_inodes_wb+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? queue_io+0x2e4/0x410 wb_writeback+0x666/0x880 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_wb_writeback+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? get_nr_dirty_inodes+0x1c/0x170 wb_workfn+0x75e/0xbb0 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x27/0x60 ? __pfx_wb_workfn+0x10/0x10 ? __pfx_debug_object_deactivate+0x10/0x10 ? lock_acquire+0x2b8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0x1e0/0x280 process_one_work+0x8d0/0x1870 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x575/0xf80 ? __pfx_worker_thread+0x10/0x10 kthread+0x2e7/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x576/0x810 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x57e/0xe10 ? __switch_to_asm+0x33/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 970: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kvmalloc_node_noprof+0x353/0x920 ntfs_rl_realloc+0x3c/0x80 ntfs_runlists_merge+0x1212/0x3010 ntfs_mft_data_extend_allocation_nolock+0x3e0/0x1f40 ntfs_mft_record_alloc+0x1ab4/0x4f10 __ntfs_create+0x680/0x2e50 ntfs_create+0x1e6/0x3a0 path_openat+0x2b55/0x3c10 do_file_open+0x1f4/0x460 do_sys_openat2+0xde/0x170 __x64_sys_openat+0x122/0x1e0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1294: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x307/0x580 ntfs_rl_realloc+0x66/0x80 ntfs_runlists_merge+0x1212/0x3010 ntfs_mft_data_extend_allocation_nolock+0x3e0/0x1f40 ntfs_mft_record_alloc+0x1ab4/0x4f10 __ntfs_create+0x680/0x2e50 ntfs_create+0x1e6/0x3a0 path_openat+0x2b55/0x3c10 do_file_open+0x1f4/0x460 do_sys_openat2+0xde/0x170 __x64_sys_openat+0x122/0x1e0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 115380f9a2f9 ("ntfs: update mft operations") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit be47c047250671c9225c0319ca4695be9b391c59 Author: David Howells Date: Thu Jul 2 09:23:02 2026 +0100 netfs: Fix barriering when walking subrequest list [ Upstream commit 5c6ce05e406520290c1d89da97fb3cd70c09137d ] Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/138807.1782980582@warthog.procyon.org.uk Reviewed-by: Paulo Alcantara (Red Hat) cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9da2e4275e6432526fda3ce02f315a0eb8c11454 Author: Karuna Ramkumar Date: Thu Jul 2 02:01:42 2026 +0000 ata: libata-scsi: limit simulated SCSI command copy to response length [ Upstream commit cd64be0ecd399fa2b1ab60b3aaf2b2b744243467 ] The function ata_scsi_rbuf_fill() is used to copy the response of emulated SCSI commands from ata_scsi_rbuf to the SCSI command's scatterlist. Currently, sg_copy_from_buffer() is called with the size argument set to ATA_SCSI_RBUF_SIZE (2048 bytes). Since ata_scsi_rbuf is zeroed out before the simulation actor is invoked, copying the full buffer size causes the remainder of the SCSI command's transfer buffer (beyond the actual response length 'len') to be overwritten with zeroes. This clobbers any pre-existing sentinel values or data in the caller's buffer tail, even though the correct residual count is reported via scsi_set_resid(). Fix this by passing the actual response length 'len' as the copy size to sg_copy_from_buffer(), ensuring that the tail of the caller's buffer remains untouched. Also, add a defensive check to ensure that the actor does not return a length exceeding the static buffer capacity. If this occurs, trigger a WARN_ON(), fail the command with an aborted command error, and return immediately without copying any data. The fix was tested by invoking an SCSI SG_IO INQUIRY on an ATA disk on vanilla build, and build with the fix. Confirmed that the input buffer's tail end remains unmodified with the fix. Fixes: 5251ae224d8d ("ata: libata-scsi: Return residual for emulated SCSI commands") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Karuna Ramkumar Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 35cb43b721c06eaea57db54bf0a13f62bed1f3d4 Author: Myeonghun Pak Date: Fri Jun 26 17:58:37 2026 +0900 ata: sata_gemini: unwind clocks on IDE pinctrl errors [ Upstream commit c0ace4130e813acbabdfaa28d4e94a849c2ffdd7 ] gemini_sata_bridge_init() prepares and enables both SATA PCLKs, then disables them again while keeping the clocks prepared for later bridge start and stop operations. If gemini_setup_ide_pins() fails after that, gemini_sata_probe() returns directly and skips the existing out_unprep_clk unwind path. Route the IDE pinctrl failure through out_unprep_clk so the clocks prepared by gemini_sata_bridge_init() are unprepared before probe fails. Fixes: d872ced29d5f ("ata: sata_gemini: Introduce explicit IDE pin control") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Niklas Cassel Reviewed-by: Linus Walleij Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 3a303f985c6bec8787c2ad4a16b39c14c5bcd765 Author: David Howells Date: Thu Jul 2 09:25:00 2026 +0100 cifs: Fix missing credit release on failure in cifs_issue_read() [ Upstream commit c16b8c4cfb4fe2244cc33e469a93c1ab8684146b ] Fix missing release of credits in the failure path in cifs_issue_read() lest retrying the subreq just overwrites the credits value. Fixes: 69c3c023af25 ("cifs: Implement netfslib hooks") Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Signed-off-by: David Howells Acked-by: Paulo Alcantara (Red Hat) cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 1acddd3e22dd6912dd5d54f80462405a1f1e6bae Author: Jiri Olsa Date: Wed Jul 1 13:13:25 2026 +0200 uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline [ Upstream commit 169328645663bae30e9abad4012d52441e085a71 ] In the unregister path we use __in_uprobe_trampoline check with current->mm for the VMA lookup, which is wrong, because we are in the tracer context, not the traced process. Add mm_struct pointer argument to __in_uprobe_trampoline and changing related callers to pass proper mm_struct pointer. Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes") Reported-by: syzbot+61ce80689253f42e6d80@syzkaller.appspotmail.com Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Acked-by: Andrii Nakryiko Tested-by: syzbot+61ce80689253f42e6d80@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260701111337.53943-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit fa8fd23e3a87ae248738b4c77ae05b5613213b64 Author: David Windsor Date: Mon Jun 29 20:13:33 2026 -0400 x86/uprobes: Keep shadow stack in sync for emulated CALLs [ Upstream commit abf08854d224085e2ebb3ba660e7995909f47d6a ] Uprobe CALL emulation updates the normal user stack, but not the CET user shadow stack. The subsequent RET then sees a stale shadow stack entry and raises #CP. Update the relative CALL emulation and XOL CALL fixup paths to keep the shadow stack in sync. Fixes: 488af8ea7131 ("x86/shstk: Wire in shadow stack interface") Signed-off-by: David Windsor Signed-off-by: Peter Zijlstra (Intel) Acked-by: Oleg Nesterov Acked-by: Jiri Olsa Tested-by: Jiri Olsa Link: https://patch.msgid.link/8b5b1c7407b98f31664ad7b6a6faf20d2d4a6cad.1782777969.git.dwindsor@gmail.com Signed-off-by: Sasha Levin commit 2b6b3f98d0e93856bee38699b783c71cb0e9d67f Author: Matthew Auld Date: Thu Jun 25 16:20:58 2026 +0100 drm/xe/pt: prevent invalid cursor access for purged BOs [ Upstream commit 8a0fb57675be578c4db19deb4298ed08a70f0f1a ] During a page table walk for binding, xe_pt_stage_bind() explicitly skips initializing the xe_res_cursor for purged BOs, treating them similarly to NULL VMAs by only setting the cursor size. However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check if the BO was purged before attempting to walk the cursor using xe_res_dma() and xe_res_next(). Because the cursor was left uninitialized for purged BOs, this falls through and triggers warnings like: WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next Fix this by explicitly checking if the BO is purged in both xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just as we do for NULL VMAs, avoiding the invalid cursor accesses entirely. As a precaution, also zero-initialize the cursor in xe_pt_stage_bind() to ensure we don't pass garbage data into the page table walkers if we ever hit a similar edge case in the future. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8418 Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Assisted-by: Copilot:gemini-3.1-pro-preview Reported-by: Matthew Schwartz Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Arvind Yadav Reviewed-by: Matthew Brost Tested-by: Matthew Schwartz Link: https://patch.msgid.link/20260625152054.450125-8-matthew.auld@intel.com (cherry picked from commit 4c7b9c6ece32440e5a435a92076d049450cd2d2e) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 5ff2212f0e0779b0b0cbf91fbf970144107c4257 Author: Matthew Auld Date: Thu Jun 25 16:20:56 2026 +0100 drm/xe: fix NPD in bo_meminfo() [ Upstream commit b5c55015d4164a0f206bcdcf2985da948b3c7837 ] When a buffer object is purged, its ttm.resource is set to NULL via the TTM pipeline gutting flow. However, the BO remains in the client's object list until userspace explicitly closes the GEM handle. If memory stats are queried during this time, accessing bo->ttm.resource->mem_type will result in a NULL pointer dereference. Fix this by safely skipping purged BOs in bo_meminfo, as they no longer consume any memory. User is getting NPD on device resume, and possible theory is that in bo_move(), if we need to evict something to SYSTEM to save the CCS state, but the BO is marked as dontneed, this won't trigger a move but will nuke the pages, leaving us with a NULL bo resource. And the meminfo() doesn't look ready to handle a NULL resource. v2 (Sashiko): - There could potentially be other cases where we might end up with a NULL resource, so make this a general NULL check for now. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8419 Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Assisted-by: Copilot:gemini-3.1-pro-preview Reported-by: Matthew Schwartz Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Arvind Yadav Reviewed-by: Matthew Brost Tested-by: Matthew Schwartz Link: https://patch.msgid.link/20260625152054.450125-6-matthew.auld@intel.com (cherry picked from commit c9a8e7daa0afe3161111e27fd92176e608c7f186) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit a4208d8032abd7f591581994f31e23b80b8fe659 Author: Michal Wajdeczko Date: Wed May 27 20:37:35 2026 +0200 drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays [ Upstream commit ed8b0d731892c68b41ecbd27c952af284816dec1 ] Currently defined VF/PF relay actions use regular REQUEST messages only and the PF shouldn't attempt to handle FAST_REQUEST nor EVENT messages as this would result in breaking the VFPF ABI protocol and also might trigger an assert on the PF side. Fixes: 98e62805921c ("drm/xe/pf: Add SR-IOV GuC Relay PF services") Signed-off-by: Michal Wajdeczko Reviewed-by: Michał Winiarski Link: https://patch.msgid.link/20260527183735.22616-1-michal.wajdeczko@intel.com (cherry picked from commit 1714d360fc5ae2e0886a69e979095d9c7ff3568a) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 23ee91355e31947595b86ebb9ef4664f20fd926d Author: Shuicheng Lin Date: Fri Jun 26 21:06:31 2026 +0000 drm/xe/hw_engine: Fix double-free of managed BO in error path [ Upstream commit 7ac3cae7a251d28e9079de07a991bd4eb2bb7fd8 ] The error path in hw_engine_init() explicitly frees a BO allocated with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm cleanup action registered, this causes a double-free when devm unwinds during probe failure. Remove the explicit free and let devm handle it, consistent with all other xe_managed_bo_create_pin_map() callers. Fixes: 0e1a47fcabc8 ("drm/xe: Add a helper for DRM device-lifetime BO create") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Zongyao Bai Link: https://patch.msgid.link/20260626210631.3887291-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit e459a3bdeb117be496d7f229e2ea1f6c9fe4080b) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit f1a1909f36b7c6eaf48ac5b42d88ee44040bc3d7 Author: Shuicheng Lin Date: Thu Jun 25 22:44:52 2026 +0000 drm/xe/userptr: Drop bogus static from finish in force_invalidate [ Upstream commit 0c56ea482aab1470b96a525ef53fa3eb8704f9a6 ] The local "finish" pointer in xe_vma_userptr_force_invalidate() is unconditionally written before each read, so the static storage class serves no purpose. Worse, it makes the variable a process-wide shared slot: the function's per-VM asserts do not exclude concurrent callers on different VMs, so two such callers can race on the slot and take the wrong if (finish) branch. The function is gated by CONFIG_DRM_XE_USERPTR_INVAL_INJECT (developer/test option, default n), so production builds are unaffected. Drop the static. Fixes: 18c4e536959e ("drm/xe/userptr: Convert invalidation to two-pass MMU notifier") Assisted-by: Claude:claude-opus-4.7 Cc: Thomas Hellström Cc: Matthew Brost Reviewed-by: Matthew Brost Reviewed-by: Zongyao Bai Link: https://patch.msgid.link/20260625224452.3243231-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit ed382e3b07fae51a09d7290485bff0592f6b168b) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit ab9ea5c943c7e780124e75b7ffad9f1c752b2579 Author: Shuicheng Lin Date: Thu Jun 25 21:56:15 2026 +0000 drm/xe/userptr: Hold notifier_lock for write on inject test path [ Upstream commit dca6e08c923a44d2d66b955e03dd57a3a38c2b94 ] When CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y, xe_pt_svm_userptr_pre_commit() runs vma_check_userptr() with the svm notifier_lock taken for read. The test injection causes vma_check_userptr() to call xe_vma_userptr_force_invalidate(), which feeds into xe_vma_userptr_do_inval() with drm_gpusvm_ctx.in_notifier=true. That flag tells drm_gpusvm_unmap_pages() the caller already holds notifier_lock for write and only asserts the mode. Because the caller actually holds it for read, the assertion fires: WARNING: drivers/gpu/drm/drm_gpusvm.c:1669 at \ drm_gpusvm_unmap_pages+0xd4/0x130 [drm_gpusvm_helper] Call Trace: xe_vma_userptr_do_inval+0x40d/0xfd0 [xe] xe_vma_userptr_invalidate_pass1+0x3e6/0x8d0 [xe] xe_vma_userptr_force_invalidate+0xde/0x290 [xe] vma_check_userptr.constprop.0+0x1c6/0x220 [xe] xe_pt_svm_userptr_pre_commit+0x6a3/0xc60 [xe] ... xe_vm_bind_ioctl+0x3a0a/0x4480 [xe] Acquire notifier_lock for write in pre-commit when the inject Kconfig is enabled, via new helpers xe_pt_svm_userptr_notifier_lock()/_unlock(). Rename xe_svm_assert_held_read() to xe_svm_assert_held_read_or_inject_write() so it asserts the correct mode under each build configuration. Production builds (CONFIG_DRM_XE_USERPTR_INVAL_INJECT=n) keep the existing read-mode behavior bit-for-bit. Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Assisted-by: Claude:claude-opus-4.7 Cc: Matthew Auld Cc: Zongyao Bai Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260625215615.3016892-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 80ccbd97ffee8ad2e73167d826fe7be548364365) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 159f9aa8d2e06eec6a5c06d44f392023efc8a726 Author: Brajesh Gupta Date: Wed Jul 1 10:49:30 2026 +0530 drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY [ Upstream commit d431b4012fd22920523dbd2806da663c1048e386 ] For a few subtypes of DRM_IOCTL_PVR_DEV_QUERY, driver was overriding the returned size unconditionally. This would have resulted in increase of reported size beyond the amount of data returned to userspace when args->size < size of query structure. Updated behaviour matches with the description of drm_pvr_ioctl_dev_query_args.size and written byte length. None of the structures of DRM_IOCTL_PVR_DEV_QUERY changed after addition, so change will not break any compatibility with earlier version. Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware loading") Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Brajesh Gupta Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260701-b4-b4-query-v2-1-a1b491387875@imgtec.com Signed-off-by: Alessio Belle Signed-off-by: Sasha Levin commit d94b9922b2ae5ee6e900f8da0bd537b251c6110c Author: Francois Dugast Date: Tue Jun 16 10:17:56 2026 +0200 drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry() [ Upstream commit 3feeb667197bd58a17f4edfdbcad249ffcb3c864 ] The page-table walk framework may pass a NULL *child pointer for unpopulated entries. xe_pt_zap_ptes_entry() called container_of(*child) before checking for NULL, then dereferenced the result, causing a crash. Move the container_of() call after a NULL guard, so the function returns early instead of proceeding with an invalid pointer. XE_WARN_ON is kept to help root cause the issue, but we now bail instead of crashing the driver. v2: Comment that triggering XE_WARN_ON is unexpected behavior (Matt Brost) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost Cc: Thomas Hellström Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20260616081756.286918-1-francois.dugast@intel.com Signed-off-by: Francois Dugast (cherry picked from commit b9297d19d9df5d4b6c994648570c5dcd1cac68ff) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 1a4421c7a5611db554328f721a4f7642440b44bd Author: David Howells Date: Thu Jun 25 15:06:32 2026 +0100 netfs: Fix folio state after ENOMEM whilst under writeback iteration [ Upstream commit b6a713fd34b9498ee2164d5d3e8460732a392efc ] Fix the state of the current folio when ENOMEM occurs during writeback iteration. The folio needs to be redirtied and unlocked before the terminal writeback_iter() is invoked. Fixes: 06fa229ceb36 ("netfs: Abstract out a rolling folio buffer implementation") Link: https://sashiko.dev/#/patchset/20260619140646.2633762-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-15-dhowells@redhat.com cc: Paulo Alcantara cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 89df9c158a25d0a7c6ca079a9bd9ca7009d75c7b Author: David Howells Date: Thu Jun 25 15:06:31 2026 +0100 netfs: Fix writeback error handling [ Upstream commit ac5f95ac5d6d0f4c567b8b642825705a2bf0d79e ] Fix the error handling in writeback_iter() loop. If an error occurs, writeback_iter() needs to be called again with *error set to the error so that it can clean up iteration state. Further, the current folio needs unlocking and redirtying. Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Link: https://sashiko.dev/#/patchset/20260619140646.2633762-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-14-dhowells@redhat.com cc: Paulo Alcantara cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0348e3fa0dfbf152af687e86ce079742b1860da9 Author: David Howells Date: Thu Jun 25 15:06:30 2026 +0100 netfs: Fix writethrough to use collection offload [ Upstream commit ba6a9f6533c77c628eef0c0c5c19cd316e2be1b4 ] Fix writethrough write to set NETFS_RREQ_OFFLOAD_COLLECTION on the request so that collection is processed asynchronously rather than only right at the end - and also so that asynchronous O_SYNC writes get collected at all. Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Closes: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-13-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 68fb8a93a34bf04554dd1111dad21775f5db8dfc Author: David Howells Date: Thu Jun 25 15:06:22 2026 +0100 cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE [ Upstream commit 511a018ed2afd8d415edd307ce7ad2048506f6a1 ] Fix cachefiles_bury_object() to lock the inode of the file being buried whilst it unsets the S_KERNEL_FILE flag. Fixes: 07a90e97400c ("cachefiles: Implement culling daemon commands") Closes: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-5-dhowells@redhat.com cc: Paulo Alcantara cc: NeilBrown cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 1188a9846fadeacf9d1430b528e5217f749d665b Author: David Howells Date: Thu Jun 25 15:06:20 2026 +0100 netfs: Fix netfs_create_write_req() to handle async cache object creation [ Upstream commit dbd6f56d975b23241b7bbb11bb8f562af548a0aa ] netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation(). Fixes: 7b589a9b45ae ("netfs: Fix handling of USE_PGPRIV2 and WRITE_TO_CACHE flags") Closes: https://sashiko.dev/#/patchset/20260624115737.2964520-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260625140640.3116900-3-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 7f7780abb4c0fdc9a2603aea8e985ff14ee900e0 Author: Morduan Zang Date: Wed Jun 24 14:26:22 2026 +0800 iomap: guard io_size EOF trim against concurrent truncate underflow [ Upstream commit 55ec50d046c03b3724741957f7b007856e36dbe7 ] iomap: fix zero padding data issue in concurrent append writes changed ioend accounting so that io_size tracks only valid data within EOF. This trims io_size when a writeback range extends past end_pos: ioend->io_size += map_len; if (ioend->io_offset + ioend->io_size > end_pos) ioend->io_size = end_pos - ioend->io_offset; However, if end_pos ends up below ioend->io_offset, the subtraction becomes negative and is stored in size_t io_size, causing an unsigned wrap to a huge value. This can happen when writeback continues past byte-level EOF up to a block-aligned range, or when a concurrent truncate shrinks the file after end_pos was sampled in iomap_writeback_handle_eof(). A wrapped io_size can mislead append detection and corrupt completion-time size handling, since filesystem end_io paths consume io_size for decisions such as on-disk EOF updates and unwritten/COW completion ranges. Fix this by clamping io_size to zero when EOF has moved to or before the ioend start offset. This preserves the original intent of trimming io_size to valid in-EOF data while avoiding the underflow. Fixes: 51d20d1dacbe ("iomap: fix zero padding data issue in concurrent append writes") Suggested-by: Christoph Hellwig Signed-off-by: Morduan Zang Link: https://patch.msgid.link/9E38E2659B47DC2A+20260624062622.337469-1-zhangdandan@uniontech.com Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 3c181e6ff1f440f9159a6246e780b400a1133b28 Author: Amir Goldstein Date: Tue Jun 9 20:46:56 2026 +0200 ovl: fix comment about locking order [ Upstream commit fd5637a2fe6dd4448392738691d63e5559fafb12 ] Forgot to update the comment when we changed the locking order. Fixes: 162d06444070c ("ovl: reorder ovl_want_write() after ovl_inode_lock()") Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260609184656.1916631-1-amir73il@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 26757dac15175f2a42e3537f1ba86e62456d48f1 Author: Hongling Zeng Date: Wed Jun 17 16:50:49 2026 +0800 cachefiles: Fix double unlock in nomem_d_alloc error path [ Upstream commit 8c256fba2b46020004201c500b2a1fbc707a33ef ] When start_creating() fails and returns -ENOMEM, it has already released the parent directory lock in __start_dirop(): static struct dentry *__start_dirop(...) { ... inode_lock_nested(dir, I_MUTEX_PARENT); dentry = lookup_one_qstr_excl(name, parent, lookup_flags); if (IS_ERR(dentry)) inode_unlock(dir); <-- Lock released on error return dentry; } However, the nomem_d_alloc error path in cachefiles_get_directory() unconditionally calls inode_unlock(d_inode(dir)) again, causing a double unlock that corrupts the rwsem state. This is a leftover from commit 7ab96df840e60 which replaced manual locking with start_creating() but failed to update the nomem_d_alloc path (while correctly updating mkdir_error and lookup_error paths). Fixes: 7ab96df840e6 ("VFS/nfsd/cachefiles/ovl: add start_creating() and end_creating()") Signed-off-by: Hongling Zeng Link: https://patch.msgid.link/20260617085049.730789-1-zenghongling@kylinos.cn Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 8a29e60e2176b02e04f8737c8b32b696230eb0c5 Author: Michael Bommarito Date: Thu Jun 18 10:39:22 2026 -0400 minix: avoid overflow in bitmap block count calculation [ Upstream commit fb3e566cafc38fe3ba35e6843a2d529a3748870c ] minix_check_superblock() uses minix_blocks_needed() to verify that the on-disk imap and zmap block counts are large enough for the advertised inode and zone counts. The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic. A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minix_fill_super() can dereference s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated. Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking the kernel. The divisor is the bitmap capacity in bits, blocksize * 8, which is always a power of two: minix_fill_super() obtains the block size through sb_set_blocksize(), and blk_validate_block_size() rejects any size that is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before adding the round-up term and so cannot overflow for a power-of-two divisor. Fixes: 8c97a6ddc956 ("minix: Add required sanity checking to minix_check_superblock()") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260618143922.3066874-1-michael.bommarito@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 27ddd3442fc6f698fb8577c7cfb243ddd81ea8c0 Author: Fengnan Chang Date: Fri Jun 12 12:40:41 2026 +0800 iomap: release pages on atomic dio size mismatch [ Upstream commit 681e452683b69a8e1a571cba0f238f8ceacf55d2 ] If bio_iov_iter_get_pages() or the bounce helper succeeds but builds a short bio, the REQ_ATOMIC size check rejects it before submission. The old error path only dropped the bio reference, leaving any pages already attached to the bio unreleased. Release or unbounce the pages before falling through to out_put_bio on this error path. This bug was reported by sashiko: https://sashiko.dev/#/patchset/20260608073134.95964-1-changfengnan%40bytedance.com Fixes: 9e0933c21c12 ("fs: iomap: Atomic write support") Signed-off-by: Fengnan Chang Link: https://patch.msgid.link/20260612044041.10677-1-changfengnan@bytedance.com Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 89ec425b454e044149322fd0d6dffd74e96b05d3 Author: David Howells Date: Mon Jun 22 10:08:55 2026 +0100 afs: Fix unchecked-length string display in debug statement [ Upstream commit 903d37c97228258da71e092f8b4ab260ce81497d ] Fix afs_extract_vlserver_list() to limit the length of the displayed string in a debug statement(). Fixes: 0a5143f2f89c ("afs: Implement VL server rotation") Closes: https://sashiko.dev/#/patchset/20260618074903.2374756-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-22-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit d0c8ad418b47891a03426c5e02ebb0537f8d68f8 Author: David Howells Date: Mon Jun 22 10:08:54 2026 +0100 afs: Fix the volume AFS_VOLUME_RM_TREE is set on [ Upstream commit 56b4e4b26f84411d880f968a539207b0a8889c8c ] Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed. Fixes: 9a6b294ab496 ("afs: Fix use-after-free due to get/remove race in volume tree") Closes: https://sashiko.dev/#/patchset/20260618074903.2374756-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-21-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit c9a0b9e5f3d4ac83b6b549a1dd31fabb970ba3a0 Author: David Howells Date: Mon Jun 22 10:08:53 2026 +0100 afs: Fix premature cell exposure through /afs [ Upstream commit 26f17ce6fa3f05cb5965790499c1839094260de4 ] AFS cell records are prematurely exposured through the /afs dynamic root by virtue of adding them immediately to the net->cells_dyn_ino IDR when the cell is allocated rather than when it is added to the lookup tree. This allows a candidate record to be accessed, even if it's actually a duplicate or not published yet. Fix this by not adding the cell to cells_dyn_ino until it's confirmed non-duplicate and is being published. A flag is then used to record whether it is added to the IDR to make removal from the IDR conditional. Closes: https://sashiko.dev/#/patchset/20260618155141.2513212-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-20-dhowells@redhat.com Fixes: 1d0b929fc070 ("afs: Change dynroot to create contents on demand") cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e94f92fd56c553a8bf9421c3289e1b85c7c08857 Author: David Howells Date: Mon Jun 22 10:08:52 2026 +0100 afs: Fix lack of locking around modifications of net->cells_dyn_ino [ Upstream commit 55e841836c6f4646490f7b0347192b7a92d431ba ] Fix the lack of locking around modifications of net->cells_dyn_ino by taking net->cells_lock exclusively. This also requires to cell to be removed from net->cells_dyn_ino in afs_destroy_cell_work() rather than in afs_cell_destroy() as the latter runs in RCU cleanup context and sleeping locks cannot be taken there. Fixes: 1d0b929fc070 ("afs: Change dynroot to create contents on demand") Closes: https://sashiko.dev/#/patchset/20260618074903.2374756-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-19-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 91d8f8e5fd34d3aed26f0fe6cf52b3f71de66cc6 Author: David Howells Date: Mon Jun 22 10:08:51 2026 +0100 afs: Fix vllist leak [ Upstream commit fc10c0ecf06f2981af5d04357612b00051e03e9e ] Fix a leak of the new vllist in afs_update_cell() in the event that it is an empty list (nr_servers == 0), in which case the old list isn't displaced unless the old list is also empty. Fixes: d5c32c89b208 ("afs: Fix cell DNS lookup") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-18-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9cabf1c86948793fbad09023bd2ec58c71b9c1d4 Author: David Howells Date: Mon Jun 22 10:08:50 2026 +0100 afs: Fix leak of ungot volume [ Upstream commit d672c276f685a540ed2b2a8bafaed4650a89022c ] Fix afs_lookup_volume_rcu() so that it doesn't leak a dying volume if afs_try_get_volume() fails. Fixes: 32222f09782f ("afs: Apply server breaks to mmap'd files in the call processor") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-17-dhowells@redhat.com cc: Marc Dionne cc: Deepakkumar Karn cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 1bdbc50e2d419c34cd6ad5b316a145ed983595dd Author: David Howells Date: Mon Jun 22 10:08:48 2026 +0100 afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff [ Upstream commit 3b1601471a88f86082fc1f1c2475645cdf59f7d8 ] This is an addendum to the patch to remove the erroneous seq |= 1 in volume lookup loop. Switch to using scoped_seqlock_read() as suggested by Oleg Nesterov[1]. Signed-off-by: David Howells Link: https://lore.kernel.org/r/aifaeKvz3KemfzaS@redhat.com/ [1] Link: https://patch.msgid.link/20260622090856.2746629-15-dhowells@redhat.com Reviewed-by: Oleg Nesterov cc: Marc Dionne cc: Li RongQing cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: d672c276f685 ("afs: Fix leak of ungot volume") Signed-off-by: Sasha Levin commit e3e59ff22a0de01ed0cf3a3e25558811abc3b70a Author: David Howells Date: Mon Jun 22 10:08:49 2026 +0100 afs: Fix missing NULL pointer check in afs_break_some_callbacks() [ Upstream commit 794a01110390c1b76f59ece773fb0fbfd89c6f5c ] Fix afs_break_some_callbacks() to check to see if afs_lookup_volume_rcu() returned NULL (e.g. the specified volume is unknown). Fixes: 8230fd8217b7 ("afs: Make callback processing more efficient.") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-16-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit f14dd036fad3d359f26f1282199cec06b3a9362b Author: David Howells Date: Mon Jun 22 10:08:47 2026 +0100 afs: Fix callback service message parsers to pass through -EAGAIN [ Upstream commit 0f36469d7ce98b362934113c550d08bb0c784231 ] The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN Fixes: d001648ec7cf ("rxrpc: Don't expose skbs to in-kernel users [ver #2]") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-14-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ebfd13c0367adb43d7c0a72f5cd7e004e60c6b28 Author: David Howells Date: Mon Jun 22 10:08:46 2026 +0100 afs: Fix reinitialisation of the inode, in particular ->lock_work [ Upstream commit 5597fbd1e7c161914f20315a726e54025b0fdadb ] It seems that initalising afs_vnode::lock_work a single time in the slab's init function isn't sufficient for work_structs. This results in the DEBUG_OBJECTS debugging stuff producing a warning occasionally when running the generic/131 xfstest: ODEBUG: activate not available (active state 0) object: 0000000016d8760f object type: work_struct hint: afs_lock_work+0x0/0x220 WARNING: lib/debugobjects.c:629 at debug_print_object+0x4b/0x90, CPU#3: locktest/7695 ... CPU: 3 UID: 0 PID: 7695 Comm: locktest Tainted: G S 7.1.0-build3+ #2771 PREEMPT ... RIP: 0010:debug_print_object+0x65/0x90 ... Call Trace: ? __pfx_afs_lock_work+0x10/0x10 debug_object_activate+0x122/0x170 insert_work+0x25/0x60 __queue_work+0x2e0/0x340 queue_delayed_work_on+0x48/0x70 afs_fl_release_private+0x57/0x70 locks_release_private+0x5c/0xa0 locks_free_lock+0xe/0x20 posix_lock_inode+0x55f/0x5b0 locks_lock_inode_wait+0x81/0x140 ? file_write_and_wait_range+0x50/0x70 afs_lock+0xcd/0x110 fcntl_setlk+0x10d/0x260 do_fcntl+0x24e/0x5b0 __do_sys_fcntl+0x6a/0x90 do_syscall_64+0x11e/0x310 entry_SYSCALL_64_after_hwframe+0x71/0x79 Fix this by reinitialising ->lock_work after allocating an inode. Also, flush ->lock_work when the inode is being evicted to make sure it's not still running. Fixes: e8d6c554126b ("AFS: implement file locking") Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-13-dhowells@redhat.com cc: Marc Dionne cc: Thomas Gleixner cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 654a546c34f3921dd03f9ea74e60139ebffd9e20 Author: David Howells Date: Mon Jun 22 10:08:45 2026 +0100 afs: Fix misplaced inc of net->cells_outstanding [ Upstream commit c9c3b615a462a4023bd148f02c564e175ed10502 ] Fix net->cells_outstanding being incremented before the check for failure of idr_alloc_cyclic(), leaving the count incremented on error. Fixes: 88c853c3f5c0 ("afs: Fix cell refcounting by splitting the usage counter") Reported-by: Hillf Danton Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-12-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 552d3c0f184a8cedb36f3840d30744681ae1a150 Author: David Howells Date: Mon Jun 22 10:08:44 2026 +0100 afs: Fix bulk lookup malfunction due to change in dir_emit() API [ Upstream commit 2f79d1b93c62470fe02dbdc24770f1ae5a9e1be6 ] afs_do_lookup() and afs_do_lookup_one() use the same directory parsing code as afs_readdir() and were supplying alternative dir_context actors to retrieve dirents, but because lookup needs the vnode's uniquifier as part of the reference, but not the DT flags, the uniquifier was being passed in the dt flags argument to the lookup actors. Unfortunately, commit c644bce62b9c, added to fix overlayfs with fuse, broke this by masking off part of the uniquifier. This doesn't matter enough to be directly noticeable, instead causing bulk advance inode lookups to fail (which are retried later) and may cause dir revalidation to malfunction if the uniquifier is changed by masking. Fix this by making the afs directory parsing code take special ->actor values of AFS_LOOKUP or AFS_LOOKUP_ONE instead that tell it to call afs_lookup_filldir() or afs_lookup_one_filldir() directly rather than going through dir_emit(). dir_emit() is still used for readdir. Fixes: c644bce62b9c ("readdir: require opt-in for d_type flags") Reported-by: Marc Dionne Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-11-dhowells@redhat.com cc: Amir Goldstein cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ca9f195050777be056f094020814d47fb4257653 Author: Li RongQing Date: Mon Jun 22 10:08:42 2026 +0100 afs: Remove erroneous seq |= 1 in volume lookup loop [ Upstream commit a58edda50a3ec08e6adac1d04dc3e488494e412d ] The `seq |= 1` operation in the volume lookup loop is incorrect because: seq is already incremented at start, making it odd in next iteration which triggers lock, but The `|= 1` operation causes seq to be even and unintended lockless operation Remove this erroneous operation to maintain proper lock sequencing. Fixes: 32222f09782f ("afs: Apply server breaks to mmap'd files in the call processor") Signed-off-by: Li RongQing Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-9-dhowells@redhat.com Reviewed-by: Oleg Nesterov cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 84e4b9232a32f0e5094dec10cf3e8187af289d0f Author: Zilin Guan Date: Mon Jun 22 10:08:41 2026 +0100 afs: use kvfree() to free memory allocated by kvcalloc() [ Upstream commit cb39654926f8e7a08ecc1dcb3941628855275940 ] op->more_files is allocated with kvcalloc() but released via afs_put_operation(), which uses kfree() internally. This mismach prevents the resource from being released properly and may lead to undefined behavior. Fix this by using kvfree() to free op->more_files to match its allocation method. Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Signed-off-by: Zilin Guan Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-8-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 6d52ff4c866ea5aeb8d74f4cd5b671878582fb03 Author: David Howells Date: Mon Jun 22 10:08:40 2026 +0100 afs: Fix directory inode initialisation order [ Upstream commit 35b177ef541ae8eefbfbf679c3476bc3fb1eb83c ] Fix afs_inode_init_from_status() to call afs_set_netfs_context() before the switch to do file type-specific initialisation because local directory changes don't get uploaded to the server, only stored in the cache. This requires that the file size be set before, so move that up too. Without this, NETFS_ICTX_SINGLE_NO_UPLOAD as set on directories gets clobbered. Closes: https://sashiko.dev/#/patchset/20260618074903.2374756-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-7-dhowells@redhat.com Fixes: 6dd80936618c ("afs: Use netfslib for directories") cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9d6b0f6d437e2f8350e08678e5e1d20c11c364f3 Author: David Howells Date: Mon Jun 22 10:08:39 2026 +0100 afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints [ Upstream commit 81e985b4c3a6cbcc443fcdcd3ebda7fcc845d459 ] Regular AFS files correctly use afs_file_aops which have release_folio set as netfs_release_folio, so AS_RELEASE_ALWAYS is valid for them when fscache is enabled (set via afs_vnode_set_cache()). Symlinks and mountpoints in AFS use afs_dir_aops, which does not provide a release_folio callback. However, afs_apply_status() unconditionally calls mapping_set_release_always() for these. In such case when memory management code attempts to release folios, filemap_release_folio() checks folio_needs_release() which returns true due to AS_RELEASE_ALWAYS being set. Since there is no release_folio callback, it falls through to try_to_free_buffers(), which at present expects buffer_heads to be not null. For symlinks and mountpoints without buffer_heads, this causes pointer dereference. [dh: Added more bits that were missed] Fixes: eae9e78951bb ("afs: Use netfslib for symlinks, allowing them to be cached") Signed-off-by: Deepakkumar Karn Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-6-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 462eada939f2d73bb814f21d5d34fe72594da2e8 Author: David Howells Date: Mon Jun 22 10:08:38 2026 +0100 afs: Fix double netfs initialisation in afs_root_iget() [ Upstream commit 733a984a4ee7345325e47efb505eebfe67b299bc ] Fix afs_root_iget() to leave initialisation of the netfs_inode part of the afs_vnode to afs_inode_init_from_status(). Fixes: bc899ee1c898 ("netfs: Add a netfs inode context") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-5-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit bdcd80ff12939d172043fac5eb822b92366a1bab Author: Dan Carpenter Date: Mon Jun 22 10:08:36 2026 +0100 afs: Fix error code in afs_extract_vl_addrs() [ Upstream commit 4897cb71d4ab1f7e1a214adb1e4b80176702368d ] The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration. Fixes: 0a5143f2f89c ("afs: Implement VL server rotation") Signed-off-by: Dan Carpenter Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-3-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 47e434da476b5a8bcd1e6e52ab03c5ee7764ee78 Author: Christian Brauner Date: Mon Jun 15 14:52:18 2026 +0200 fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid [ Upstream commit 539dce1144651f7976fa418e618b0b574bf15eeb ] vfs_tmpfile() never checked that the caller's fsuid and fsgid map into the filesystem. On an idmapped mount whose idmapping does not cover the caller's fs{u,g}id, the ->tmpfile() instance initializes the new inode through inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return INVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1. Every other creation path already refuses this: may_o_create() (O_CREAT) and may_create_dentry() (mkdir, mknod, symlink, link) bail out with -EOVERFLOW via fsuidgid_has_mapping() precisely so that an object cannot be created with an owner the filesystem cannot represent. An O_TMPFILE is no exception: it is created I_LINKABLE and linkat(2) can splice it into the namespace afterwards, so the same guarantee must hold. Add the missing fsuidgid_has_mapping() check to vfs_tmpfile(). On a non-idmapped mount the caller's fs{u,g}id always map in the superblock's user namespace, so this is a no-op there and only takes effect on an idmapped mount that does not map the caller. It applies to every filesystem that sets FS_ALLOW_IDMAP and implements ->tmpfile() (tmpfs, ext4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer tmpfile creation funnels through vfs_tmpfile() via backing_tmpfile_open(). Fixes: 8e5389132ab4 ("fs: introduce fsuidgid_has_mapping() helper") Link: https://patch.msgid.link/20260615-work-idmapped-tmpfile-v1-1-754a94d81f83@kernel.org Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit fc9332533a58584293e32cb4f8e52b0be4bb1e13 Author: Samuel Moelius Date: Mon Jun 29 16:44:59 2026 +0000 net/sched: hhf: clear heavy-hitter state on reset [ Upstream commit a225f8c20712713406ae47024b8df42deacddd4a ] HHF reset does not clear the classifier state used to identify heavy hitters. Packets after reset can therefore be scheduled using flow history from before the reset. The reset operation should return the qdisc to an empty state. Clear the heavy-hitter classifier tables when HHF is reset. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d25cdea6226cef890a2884ceafa187cb078d69c1 Author: Samuel Moelius Date: Sun Jun 28 13:48:47 2026 +0000 net/sched: dualpi2: clear stale classification on filter miss [ Upstream commit bf83ee45874e9f071478bed39f9cf40cc741629f ] DualPI2 leaves previous classification state attached to an skb when filter classification returns no match. The enqueue path can then act on stale state from an earlier classification attempt. A filter miss should fall back to the default class without reusing old per-packet classification data. Initialize the classification result to CLASSIC before running the classifier. Explicit L4S, priority, and successful filter classification can still override that default. Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1297a9e2fd6ce08678b370d41bc980ca798f809 Author: Michael Bommarito Date: Tue Jun 16 21:41:49 2026 -0400 xen/pvcalls: bound backend response req_id before indexing rsp[] [ Upstream commit d33846c8dcc06b83b7acdeac1e8bfbb5c0c26cb2 ] pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends. A backend that sends an out-of-range req_id has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenvif_fatal_tx_err()). The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments). Fixes: 2195046bfd69 ("xen/pvcalls: implement socket command and handle events") Suggested-by: Juergen Gross Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260617014149.2647404-1-michael.bommarito@gmail.com> Signed-off-by: Sasha Levin commit feba85c0eeda85d730fe8bcd6c0be8eb5e2b40d4 Author: Viacheslav Bocharov Date: Thu Jun 25 14:57:18 2026 +0300 pinctrl: meson: restore non-sleeping GPIO access [ Upstream commit 9777530157e7b82fd994327ff878c4245dadc931 ] Commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") set gpio_chip.can_sleep = true to work around gpio-shared-proxy holding a spinlock across a sleeping pinctrl config path. That locking bug is now fixed in the shared-proxy itself ("gpio: shared-proxy: always serialize with a sleeping mutex"), so the controller-wide workaround is no longer needed; the meson GPIO controller does not sleep. meson_gpio_get/set/direction_* access MMIO through regmap. The regmap_mmio bus uses fast I/O (spinlock) locking, so these value callbacks do not contain sleeping operations. Since gpio_chip.can_sleep describes the get/set value path, restore can_sleep = false. Marking the controller sleeping also broke atomic value consumers such as w1-gpio (1-Wire bitbang): w1_io.c runs its read time slot under local_irq_save() and uses the non-cansleep gpiod_set_value() / gpiod_get_value(), which with can_sleep=true trigger WARN_ON(can_sleep) in gpiolib on every transferred bit (from w1_gpio_write_bit() / w1_gpio_read_bit() via w1_reset_bus() and w1_search()). The printk and stack dump inside the IRQs-off, microsecond-scale time slot destroy the bit timing, so reset/presence detection and ROM search fail: the bus master registers but w1_master_slave_count stays at 0 and no devices are found. Verified on an Amlogic A113X board (DS18B20 on GPIOA_14): with can_sleep restored to false the warnings are gone and the sensor is detected and read again. This must not be applied or backported without the shared-proxy locking fix above; otherwise the original Khadas VIM3 splat returns on boards that genuinely share a meson GPIO. Fixes: 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") Link: https://lore.kernel.org/all/20260105150509.56537-1-bartosz.golaszewski@oss.qualcomm.com/ Signed-off-by: Viacheslav Bocharov Acked-by: Linus Walleij Link: https://patch.msgid.link/20260625115718.1678991-3-v@baodeep.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 2ef42bd9a8b7a99fbbe3e0b825783ca145ba27c0 Author: Vladimir Zapolskiy Date: Tue Jun 30 17:51:48 2026 +0300 gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe [ Upstream commit 8d7e62d5e9b2d2ff146f472a9215d7e29c7e2307 ] Out of memory situation on driver's probe is expected to be reported to the driver's framework with a proper -ENOMEM error code. Fixes: 35570ac6039e ("gpio: add GPIO driver for the Timberdale FPGA") Signed-off-by: Vladimir Zapolskiy Link: https://patch.msgid.link/20260630145148.4081967-1-vz@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit ed98719be41389d416953b8ef9f07a07dfea6b2b Author: Gil Portnoy Date: Fri Jun 26 20:38:20 2026 +0300 ksmbd: fix use-after-free of fp->owner.name in durable handle owner check [ Upstream commit 38637163501fd9e2f684b8cd275d0db5d79f37c6 ] Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d ("ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify. Fixes: 49110a8ce654 ("ksmbd: validate owner of durable handle on reconnect") Assisted-by: Henry (Claude):claude-opus-4 Signed-off-by: Gil Portnoy Co-developed-by: Namjae Jeon Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 15a9e9b8f7f5d7f380ae54c6f5bcbc0bdcb0f3cd Author: Haofeng Li Date: Thu Jun 25 14:48:07 2026 +0000 ksmbd: reject undersized DACLs before parsing ACEs [ Upstream commit 60908f7ebcd9b6cde74ad5711fab0f49c7970949 ] parse_dacl() limits the attacker-controlled ACE count by comparing it with the number of minimal ACEs that fit in the DACL size. The DACL size field is 16 bits, but the expression subtracts sizeof(struct smb_acl). Because sizeof() is unsigned, a DACL size smaller than the ACL header underflows to a large size_t. A malicious client can reach this with: SMB2_SET_INFO (InfoType=SMB2_O_INFO_SECURITY) -> smb2_set_info_sec() -> set_info_sec() -> parse_sec_desc() -> parse_dacl() -> init_acl_state(..., 0xffff) -> init_acl_state(..., 0xffff) -> kmalloc_objs(..., 0xffff) Thus a malformed security descriptor can make num_aces pass the guard and drive large temporary ACL state and pointer-array allocations. Reject DACLs smaller than struct smb_acl before doing the subtraction, so the ACE count check cannot be bypassed by the underflow. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Haofeng Li Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b0933dede95d525bad44d593d35cb8cee75cbe20 Author: Sechang Lim Date: Mon Jun 29 15:41:06 2026 +0000 net/sched: act_bpf: use rcu_dereference_bh() to read the filter [ Upstream commit adc49c7ba690c9b33b8392ec27397456b65d0893 ] tcf_bpf_act() can run from the tc egress path, which holds only rcu_read_lock_bh(), but reads prog->filter with rcu_dereference() and trips lockdep: WARNING: suspicious RCU usage net/sched/act_bpf.c:47 suspicious rcu_dereference_check() usage! 1 lock held by syz.2.1588/12756: #0: (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit net/core/dev.c:4792 tcf_bpf_act+0x6ae/0x940 net/sched/act_bpf.c:47 tcf_classify+0x6e4/0x1080 net/sched/cls_api.c:1860 sch_handle_egress net/core/dev.c:4545 [inline] __dev_queue_xmit+0x2185/0x2c00 net/core/dev.c:4808 packet_sendmsg+0x3dfa/0x5120 net/packet/af_packet.c:3114 The other tc actions and cls_bpf already use rcu_dereference_bh() here. Do the same. Fixes: 1f211a1b929c ("net, sched: add clsact qdisc") Signed-off-by: Sechang Lim Reviewed-by: Amery Hung Link: https://patch.msgid.link/20260629154112.1164986-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 24e63c47668a7cdb4aa0ae77f22e40e0b7745bca Author: Jakub Kicinski Date: Mon Jun 29 16:39:23 2026 -0700 selftests: drv-net: tso: don't touch dangerous feature bits [ Upstream commit 2f7f2e311106cb838d3f3fb6ef25effdb3f8e366 ] query_nic_features() detects which offloads depend on tx-gso-partial by enabling everything, turning tx-gso-partial off, and seeing which active features drop out. Enabling all hw features is dangerous: we may end up enabling rx-fcs and loopback for example. For the ice driver we end up getting into problems with feature dependencies so the cleanup isn't successful either, and the test exits with rx-fcs and loopback enabled. Scope the feature probing just to segmentation bits. Fixes: 266b835e5e84 ("selftests: drv-net: tso: enable test cases based on hw_features") Reviewed-by: Pavan Chebbi Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/20260629233923.2151144-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9717091371d71984f1773b4c679690690ff4acf8 Author: Gleb Markov Date: Mon Jun 29 16:08:54 2026 +0300 cxgb4: Fix decode strings dump for T6 adapters [ Upstream commit 5d6dc22d62682d93f5f55f145ad792f2891de911 ] Depending on the value of chip_version, the correct decode set is selected. However, the subsequent matching with the t4 encoding type in the if-else block results in a reassignment, which leads to the loss of support for t6_decode as well as reinitializing of values t4_decode and t5_decode. The component history shows that the if-else block previously used for this purpose, as well as the execution order, was not affected by the change. Furthermore, it is suggested by the execution order that the scenario with overwriting and loss of support will be implemented. Delete the if-else block. Fixes: 6df397539cb0 ("cxgb4: Update correct encoding of SGE Ingress DMA States for T6 adapter") Signed-off-by: Gleb Markov Reviewed-by: Potnuri Bharat Teja Link: https://patch.msgid.link/20260629130856.1168-1-markov.gi@npc-ksb.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 13741bad74d452d21ac6bdcca39804405581f03a Author: Longjun Tang Date: Mon Jun 29 10:42:30 2026 +0800 virtio_net: disable cb when NAPI is busy-polled [ Upstream commit 1eb8fc67ca41db71c90866ff76c990d85247daef ] When busy-poll is active, napi_schedule_prep() returns false in virtqueue_napi_schedule(), so virtqueue_disable_cb() is skipped. The device may keep firing irqs until reaches virtqueue_napi_complete(). Under load (received == budget), it will lead to a large number of spurious interrupts. Fix it by disabling the callback at the virtnet_poll() entry. This keeps the callback off while we poll and it is re-enabled by virtqueue_napi_complete() when going idle. Fixes: ceef438d613f ("virtio_net: remove custom busy_poll") Acked-by: Michael S. Tsirkin Signed-off-by: Longjun Tang Link: https://patch.msgid.link/20260629024230.37325-1-lange_tang@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c3e5cac47519d77ad36b9c03a1df1536aaa0c4a1 Author: Xin Long Date: Mon Jun 29 14:31:14 2026 -0400 sctp: fix addr_wq_timer race in sctp_free_addr_wq() [ Upstream commit 976c19de0f22a857ba0112f39635f8fd7a257568 ] sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete() while holding addr_wq_lock. However, timer_delete() does not guarantee that a currently running timer handler has completed. This allows a race with sctp_addr_wq_timeout_handler(), where the handler may still run after addr_waitq has been freed, acquire addr_wq_lock, and access freed memory, leading to a use-after-free. Fix this by calling timer_shutdown_sync() before taking addr_wq_lock. This guarantees that any in-flight timer handler has finished and prevents the timer from being re-armed during teardown, making subsequent cleanup safe. Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace") Reported-by: Sashiko Signed-off-by: Xin Long Link: https://patch.msgid.link/5dc95f295bdb5c3f60e880dd9aa5112dc5c071cc.1782757874.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac39628cb3ef66a305d5cc5aa25ea64404e2032a Author: Felix Gu Date: Sat Jun 27 00:02:29 2026 +0800 spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption [ Upstream commit 7fc2c3dcae28347a30ccd76c8817e5719005f1c3 ] wait_event_interruptible_timeout() can return a negative error code when interrupted by a signal. The original code treated all non-zero return values as success, which would incorrectly synchronize DMA channels and return 0 instead of propagating the interruption error. Fixes: fa08b566860b ("spi: rzv2h-rspi: add support for DMA mode") Signed-off-by: Felix Gu Reviewed-by: Cosmin Tanislav Tested-by: Cosmin Tanislav Reviewed-by: Wolfram Sang Link: https://patch.msgid.link/20260627-rspi-v1-1-170c93ee14da@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9ed0dca2aa05908b33ecf0bb15c7953947529542 Author: Qingshuang Fu Date: Tue Jun 23 09:52:11 2026 +0800 irqchip/ts4800: Fix missing chained handler cleanup on remove [ Upstream commit 98bf7e54cec07d514b3575c11896a8b12d50ecc4 ] The driver installs a chained handler for the parent interrupt during probe using irq_set_chained_handler_and_data(), but the remove function does not clear this handler. This leaves a dangling handler that may be called when the parent interrupt fires after the driver has been removed, potentially accessing freed memory and causing a kernel crash. Additionally, the parent_irq obtained via irq_of_parse_and_map() is not stored, making it inaccessible in the remove function. Moreover, interrupt mappings created during probe are not properly disposed. Fix this by: - Saving parent_irq in probe - Clearing the chained handler with NULL in ts4800_ic_remove() - Disposing all IRQ mappings before domain removal to prevent resource leaks Fixes: d01f8633d52e ("irqchip/ts4800: Add TS-4800 interrupt controller") Signed-off-by: Qingshuang Fu Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260623015211.109382-1-fffsqian@163.com Signed-off-by: Sasha Levin commit 5459f4f32a8eb78908348c8a0fd6a89221247a08 Author: Yuho Choi Date: Sun Jun 28 18:07:23 2026 -0400 irqchip/gic-v3-its: Fix OF node reference leak [ Upstream commit 2e1368a9d61bdf5502ddade004f223a5831c5b8c ] of_get_cpu_node() returns a referenced device node. In its_cpu_init_collection(), the Cavium 23144 workaround only uses the node to compare the CPU NUMA node, but the reference is never dropped. Use the device_node cleanup helper for the CPU node reference so it is released when leaving the workaround block, including the NUMA mismatch return path. Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144") Signed-off-by: Yuho Choi Signed-off-by: Thomas Gleixner Reviewed-by: Zenghui Yu (Huawei) Acked-by: Marc Zyngier Signed-off-by: Sasha Levin commit 57e1f2cd6a0e890ee2eadbd93de3dcd5e22653a5 Author: Masami Hiramatsu (Google) Date: Thu Jun 25 08:34:48 2026 +0900 tracing/probes: Make the $ prefix mandatory for comm access [ Upstream commit a369299c3f785cf556bbef2de2db0aa2d294c4c9 ] Since $comm or $COMM are not event field but special fetcharg variables to access current->comm, It should not be accessed without '$' prefix even with typecast. Link: https://lore.kernel.org/all/178231209724.732967.12049805699091810641.stgit@devnote2/ Fixes: 69efd863a785 ("tracing/eprobes: Allow use of BTF names to dereference pointers") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit d655cca1c6e67eb081214d37eb231a869ead2f97 Author: Sechang Lim Date: Thu Jun 25 08:34:48 2026 +0900 tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry() [ Upstream commit 367c49d6e283c17b56a31e7a8d964a079244264c ] fprobe_fgraph_entry() sizes a shadow-stack reservation in one walk of the per-ip fprobe list and fills it in a second walk, both under rcu_read_lock() only. A fprobe registered on an already-live ip can become visible between the two walks, so the fill walk processes an exit_handler the sizing walk did not count and used runs past reserved_words. If the sizing walk counted nothing, fgraph_data is NULL and the first write_fprobe_header() faults: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:fprobe_fgraph_entry+0xa38/0xf10 kernel/trace/fprobe.c:167 Call Trace: function_graph_enter_regs+0x44c/0xa10 kernel/trace/fgraph.c:677 ftrace_graph_func+0xc5/0x140 arch/x86/kernel/ftrace.c:671 __kernel_text_address+0x9/0x40 kernel/extable.c:78 arch_stack_walk+0x117/0x170 arch/x86/kernel/stacktrace.c:26 kmem_cache_free+0x188/0x580 mm/slub.c:6378 tcp_data_queue+0x18d/0x6550 net/ipv4/tcp_input.c:5590 [...] The list cannot be frozen across the two walks, so skip a node that does not fit the reservation and count it as missed. Link: https://lore.kernel.org/all/20260619184425.3824774-1-rhkrqnwk98@gmail.com/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Signed-off-by: Sechang Lim Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit f4461db8eb8ed375917c38d93d6def60e3bb06b0 Author: Martin Kaiser Date: Thu Jun 25 08:34:46 2026 +0900 tracing: eprobe: read the complete FILTER_PTR_STRING pointer [ Upstream commit 206b25c09080cc20fd4c2bea12d59df4b7ba2121 ] For a char * element in an event, the FILTER_PTR_STRING filter type is used. When the event occurs, a pointer is stored in the ringbuffer. If an eprobe references such a char * element of a "base event", the stored pointer is truncated when it's read from the ringbuffer. $ cd /sys/kernel/tracing $ echo 'e rcu.rcu_utilization $s:x64 $s:string' > dynamic_events $ echo 1 > tracing_on $ echo 1 > events/eprobes/enable $ sleep 1 $ echo 0 > events/eprobes/enable $ cat trace -0 ...: (rcu.rcu_utilization) arg1=0x4f arg2=(fault) -0 ...: (rcu.rcu_utilization) arg1=0x2 arg2=(fault) The problem is in get_event_field val = (unsigned long)(*(char *)addr); addr points to the position in the ringbuffer where the pointer was stored. The assignment reads only the lowest byte of the pointer. Fix the cast to read the whole pointer. The output of the test above is now -0 ... arg1=0xffffffff81c7d3f3 arg2="Start scheduler-tick" -0 ... arg1=0xffffffff81c57340 arg2="End scheduler-tick" Link: https://lore.kernel.org/all/20260620145339.3234726-1-martin@kaiser.cx/ Fixes: f04dec93466a ("tracing/eprobes: Fix reading of string fields") Signed-off-by: Martin Kaiser Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 10a33029e1cf9edf441bb91ec9f4a161ca97ca3a Author: Masami Hiramatsu (Google) Date: Thu Jun 25 08:34:46 2026 +0900 tracing/events: Fix to check the simple_tsk_fn creation [ Upstream commit cda1fbfc5313bb90daa271d45eea4a8d317a8544 ] Sashiko pointed that this sample code does not correctly handle the failure of thread creation because kthread_run() can return -errno. Check the simple_tsk_fn is correctly initialized (created) or not. Link: https://lore.kernel.org/all/178165817322.269421.3992299509400184196.stgit@devnote2/ Link: https://sashiko.dev/#/patchset/178092865666.163648.10457567771536160909.stgit%40devnote2 Fixes: 9cfe06f8cd5c ("tracing/events: add trace-events-sample") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 8a662d8c05e2cf16f7a047c81bc1eb5d3b29bacd Author: Masami Hiramatsu (Google) Date: Thu Jun 25 08:34:46 2026 +0900 tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg [ Upstream commit 251a8fe1b9aedccd298b77bc28426d564c5a923f ] Sashiko found that user can cause this WARN_ON_ONCE() easily with adding a kprobe event based on a raw address with BTF parameter. Since this is not an unexpected condition, remove the WARN_ON_ONCE(). Link: https://lore.kernel.org/all/178177265367.2059927.13789953014706792126.stgit@mhiramat.tok.corp.google.com/ Link: https://sashiko.dev/#/patchset/178165816303.269421.7302603996990753309.stgit%40devnote2 Reported-by: Sashiko Fixes: b576e09701c7 ("tracing/probes: Support function parameters if BTF is available") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 9acf6f34eb4875767e1684b9c469cf5ceb40fc69 Author: Steven Rostedt Date: Mon Jun 1 13:07:46 2026 -0400 tracing/eprobes: Allow use of BTF names to dereference pointers [ Upstream commit 69efd863a78584b9416ed6be0e1e7349124b4a00 ] Add syntax to the parsing of eprobes to be able to typecast a trace event field that is a pointer to a structure. Currently, a dereference must be a number, where the user has to figure out manually the offset of a member of a structure that they want to dereference. But for event probes that records a field that happens to be a pointer to a structure, it cannot dereference these values with BTF naming, but must use numerical offsets. For example, to find out what device a sk_buff is pointing to in the net_dev_xmit trace event, one must first use gdb to find the offsets of the members of the structures: (gdb) p &((struct sk_buff *)0)->dev $1 = (struct net_device **) 0x10 (gdb) p &((struct net_device *)0)->name $2 = (char (*)[16]) 0x118 And then use the raw numbers to dereference: # echo 'e:xmit net.net_dev_xmit +0x118(+0x10($skbaddr)):string' >> dynamic_events If BTF is in the kernel, then instead, the skbaddr can be typecast to sk_buff and use the normal dereference logic. # echo 'e:xmit net.net_dev_xmit (sk_buff)skbaddr->dev->name:string' >> dynamic_events # echo 1 > events/eprobes/xmit/enable # cat trace [..] sshd-session-1022 [000] b..2. 860.249343: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.250061: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.250142: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.263553: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.283820: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.302716: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.322905: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.342828: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.362268: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.382335: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.400856: xmit: (net.net_dev_xmit) arg1="enp7s0" sshd-session-1022 [000] b..2. 860.419893: xmit: (net.net_dev_xmit) arg1="enp7s0" The syntax is simply: (STRUCT)(FIELD)->MEMBER[->MEMBER..] Also add comments around the #else and #endif of #ifdef CONFIG_PROBE_EVENTS_BTF_ARGS to know what they are for. Link: https://lore.kernel.org/all/20260601130746.2139d926@gandalf.local.home/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 251a8fe1b9ae ("tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg") Signed-off-by: Sasha Levin commit 2c88ad0d06c6b043bb4c5b04e78ce80639bf9e33 Author: Boris Brezillon Date: Thu Jun 25 14:40:36 2026 +0200 drm/panthor: Interrupt group start/resumption if group_bind_locked() fails [ Upstream commit 1f27cef1f41dac0bd254d8741766f189936c9880 ] group_bind_locked() can fail if the MMU block is stuck. This is normally a reset situation, but by the time we reset the GPU, we might have tried to resume a group that's not resident, which will probably trip out the FW. So let's avoid that by bailing out when group_bind_locked() returns an error. We don't even try to start more groups because the GPU will be reset anyway. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=7 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-10-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 893ed1a7c837a824b2a25543e46fbf19dc41f6b5 Author: Boris Brezillon Date: Thu Jun 25 14:40:35 2026 +0200 drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced [ Upstream commit 6efeb9ddb4fbf5ac30aff03e8f09ffbdf966abd0 ] A group ref is tied to the pending tiler_oom_work, so we need to release it if the cancel was effective. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=7 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-9-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 50556bfe1d6c6b137882a713a393bea737fbd095 Author: Boris Brezillon Date: Thu Jun 25 14:40:33 2026 +0200 drm/panthor: Fix panthor_pwr_unplug() [ Upstream commit e62179fd3e23ecfaedf7101e19ec0d3e4f51de76 ] We can't call panthor_pwr_irq_suspend() if the device is suspended, or this leads to a hang when the IOMEM region is accessed while the clks are disabled. Do what other sub-components do and conditionally call panthor_pwr_irq_suspend() if we know the PWR regbank block is accessible. Fixes: c27787f2b77f ("drm/panthor: Introduce panthor_pwr API and power control framework") Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-7-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 1352cd192e5beff397251bef7a9a60dccb1c8712 Author: Boris Brezillon Date: Thu Jun 25 14:40:32 2026 +0200 drm/panthor: Don't overrule pending immediate ticks in sched_resume_tick() [ Upstream commit 6fec8b473497b7f32e604a6dd92b32b0889af3e8 ] We schedule immediate ticks when we need to process events on CSGs, but those immediate ticks don't change the resched_target because we want the other groups to stay scheduled for the remaining of the GPU timeslot they were given. Make sure these immediate ticks don't get overruled by a sched_queue_delayed_work() that would delay the tick execution. Fixes: 99820b4b7e50 ("drm/panthor: Make sure we resume the tick when new jobs are submitted") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=9 Signed-off-by: Boris Brezillon Reviewed-by: Karunika Choo Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-6-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 361adc5343e98588d149627f77dffb71eb9829d0 Author: Boris Brezillon Date: Thu Jun 25 14:40:31 2026 +0200 drm/panthor: Fix theoretical IOMEM access in suspended state [ Upstream commit fe4c05a59018964bac7923338706371fff3c09ef ] In theory, our hardirq handler can be called while the device (and thus the panthor_irq) is suspended, because the IRQ line is shared. In practice though, in all the designs we've seen, the line is only shared within the GPU, and because sub-component suspend state is consistent (all-suspended or all-resumed), we shouldn't end up with an interrupt triggered while we're suspended. Fix the problem anyway, if nothing else, for our sanity. Fixes: 0b2d86670a84 ("drm/panthor: Rework panthor_irq::suspended into panthor_irq::state") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=1 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-5-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 1c942c3c51795f7a6c422e6bac10b4f4a01036e7 Author: Karunika Choo Date: Mon Apr 27 16:59:30 2026 +0100 drm/panthor: Store IRQ register base iomem pointer in panthor_irq [ Upstream commit 77e5cc60fa172047ad3460f74db0699b3a7746f9 ] Update common IRQ handling code to work from an IRQ-local iomem base instead of referencing block-specific interrupt register offsets. Store the interrupt base address iomem pointer in struct panthor_irq and switch the shared IRQ helpers to use generic INT_* offsets from that local base. This removes the need for each caller to expose absolute IRQ register addresses while keeping the common IRQ flow unchanged. No functional change intended. v3: - Clean up definition of pwr->irq.iomem. v2: - Change IRQ request function to accept an iomem pointer instead of computing it from an offset argument. Signed-off-by: Karunika Choo Reviewed-by: Boris Brezillon Tested-by: Boris Brezillon Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260427155934.416502-5-karunika.choo@arm.com Stable-dep-of: fe4c05a59018 ("drm/panthor: Fix theoretical IOMEM access in suspended state") Signed-off-by: Sasha Levin commit 34eb9945a07557f94678bd073527eaa15749142a Author: Karunika Choo Date: Mon Apr 27 16:59:28 2026 +0100 drm/panthor: Split register definitions by components [ Upstream commit 1f0a27ba793f3b9b5cf46f16157da41303b4aa88 ] Split the panthor register definitions into per-component headers for the GPU, MMU, firmware, power and generic hardware registers. This makes the register layout easier to follow and prepares the driver for component-local iomem mappings by grouping definitions with the code that owns them. The old monolithic panthor_regs.h header can then be dropped. No functional change intended. v3: - Pick up Ack from Boris and R-bs from Liviu and Steve v2: - Merge GPU_ID definitions into panthor_gpu_regs.h - deleted panthor_hw_regs.h Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Acked-by: Boris Brezillon Signed-off-by: Karunika Choo Tested-by: Boris Brezillon Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260427155934.416502-3-karunika.choo@arm.com Stable-dep-of: fe4c05a59018 ("drm/panthor: Fix theoretical IOMEM access in suspended state") Signed-off-by: Sasha Levin commit 85c6f80499e679aecca915810168cbe181df5b77 Author: Karunika Choo Date: Mon Apr 27 16:59:27 2026 +0100 drm/panthor: Pass an iomem pointer to GPU register access helpers [ Upstream commit a8f5738779a930b4f318104298ce84bc10d43fbc ] Convert the Panthor register access helpers to take an iomem pointer instead of a panthor_device pointer. This makes the helpers usable with block-local registers instead of routing all accesses to go through ptdev->iomem. It is a preparatory change for splitting the register space by components and for moving callers away from cross-component register accesses. No functional change intended. v3: - Pick up R-bs from Liviu and Steve v2: - Pick up Ack from Boris. Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Acked-by: Boris Brezillon Signed-off-by: Karunika Choo Tested-by: Boris Brezillon Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260427155934.416502-2-karunika.choo@arm.com Stable-dep-of: fe4c05a59018 ("drm/panthor: Fix theoretical IOMEM access in suspended state") Signed-off-by: Sasha Levin commit 053522ba615888e874adc04e675d9ed2e13f35af Author: Boris Brezillon Date: Thu Jun 25 14:40:30 2026 +0200 drm/panthor: Fix potential invalid pointer deref in group_process_tiler_oom() [ Upstream commit b39436d0ba1571dbcda69d20ec567344b3eecfc7 ] If heaps is an ERR_PTR(), panthor_heap_pool_put() will deref an invalid pointer. Make sure we set it to NULL in that case. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=2 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-4-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 752a08cfeeeac10adf961826831c719e7b7e87fb Author: Boris Brezillon Date: Thu Jun 25 14:40:28 2026 +0200 drm/panthor: Keep the reset work disabled until everything is initialized [ Upstream commit 1b8d771fb214e1f783d66caf13d35d7eda39a643 ] The reset work will sub-component reset helpers, which might not be ready if the reset happens during initialization, leading to NULL pointer dereferences or worse. Avoid that by keeping the reset work disabled while we're initializing those sub-components. Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=4 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-2-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 2946aa6c97ac0e0d777baef8c0e6d944da8724a3 Author: Boris Brezillon Date: Thu Jun 25 14:40:27 2026 +0200 drm/panthor: Always use the IRQ-safe variant when acquiring the fence lock [ Upstream commit 778c57d624974e64535ef1c9d9b4d8e5066153f4 ] Since dma_fence objects can be shared with other subsystems, they may be accessed from hardirq context in those drivers, and we have to take that into account by also using the IRQ-safe variant when acquiring the lock. While at it, switch to the guard model. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=11 Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-1-b67ed973fea6@collabora.com Signed-off-by: Sasha Levin commit 8a277a20258d4435973faa9ccd3ca863f2abd76a Author: Viacheslav Bocharov Date: Tue Jun 30 13:15:44 2026 +0300 gpio: shared-proxy: always serialize with a sleeping mutex [ Upstream commit efecde8a254d1f207b75c5ebcfba2c51f4c771d9 ] The shared GPIO descriptor used either a mutex or a spinlock, chosen at runtime from the underlying chip's can_sleep: shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc); ... if (can_sleep) mutex_lock(); else spin_lock_irqsave(); can_sleep describes only the value path (->get/->set). Under the same lock, however, the proxy may call gpiod_set_config() and gpiod_direction_*(), which can reach pinctrl paths that take a mutex (e.g. gpiod_set_config() -> gpiochip_generic_config() -> pinctrl_gpio_set_config()), independent of can_sleep. On a controller with non-sleeping MMIO value ops the descriptor lock was a spinlock, so the sleeping pinctrl call ran from atomic context. Reproduced on an Amlogic A113X board with the workaround from commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the original Khadas VIM3 report hit the same path: BUG: sleeping function called from invalid context __mutex_lock pinctrl_get_device_gpio_range pinctrl_gpio_set_config gpiochip_generic_config gpiod_set_config gpio_shared_proxy_set_config <- voting spinlock held ... mmc_pwrseq_simple_probe The spinlock existed to take the value vote from atomic context, but the vote and the (possibly sleeping) control operations share the same state and lock, so this scheme cannot serialize config under a mutex and still offer atomic value access. Always serialize the shared descriptor with a mutex instead and mark the proxy a sleeping gpiochip, driving the underlying GPIO through the cansleep value accessors: those are valid for both sleeping and non-sleeping chips, so value access keeps working on fast controllers, at the cost of no longer being atomic. With every vote edge now driven through the cansleep value setter, gpio_shared_proxy_set_unlocked() no longer needs a per-call setter: drop its set_func callback and call gpiod_set_value_cansleep() directly. The shared direction_output path reaches it only once the line is already an output, so driving the value there is equivalent to re-issuing gpiod_direction_output(), without the redundant per-edge re-assertion of drive config and bias. This is observable: consumers gating on gpiod_cansleep() take their sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its emergency-restart reset handler; its normal reset is unaffected), and consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would fail to probe. Such atomic users do not share a pin through the proxy, whose purpose is voting on shared reset/enable lines. The same narrowing already applies on Amlogic since that workaround, and rockchip addressed the identical splat per-driver in commit 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction"); fixing the proxy addresses the locking error once, for every controller. The lock type was added by commit a060b8c511ab ("gpiolib: implement low-level, shared GPIO support"); the sleeping call under it arrived with the proxy driver. Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver") Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/ Signed-off-by: Viacheslav Bocharov Link: https://patch.msgid.link/20260630101545.800625-2-v@baodeep.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 40cbfa3a28e0919469d1b086629bb3ce38a83593 Author: Ido Schimmel Date: Mon Jun 29 10:21:17 2026 +0300 bridge: stp: Fix a potential use-after-free when deleting a bridge [ Upstream commit 2a00517db8de4be7df3d483b215c5544fb30a191 ] The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Noam Rathaus Reported-by: Neil Young Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260629072117.497959-1-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b26aa9d993537a4c3167d8ceead3b7c69c3a0aac Author: Jamal Hadi Salim Date: Sun Jun 28 07:12:29 2026 -0400 net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF [ Upstream commit e5b811fe793166aecc59b085c1b7c31262ef2316 ] The teql master->slaves singly linked list is not protected against multiple writes. It can be mod'ed concurently from teql_master_xmit(), teql_dequeue(), teql_init() and teql_destroy() without holding any list lock or RCU protection. zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed after an RCU grace period, but teql_master_xmit() running on another CPU can still hold a stale pointer into the list, resulting in a slab-use-after-free: BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0 Read of size 8 at addr ffff888013fb0440 by task poc/332 Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512) The fix? Add a per-master slaves_lock spinlock that serializes all mutations of master->slaves and the NEXT_SLAVE() links in teql_destroy() and teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock around those updates. Annotate master->slaves and the per-slave ->next pointer with __rcu and use the appropriate RCU accessors everywhere they are touched: rcu_assign_pointer() on the writer side (under slaves_lock), rcu_dereference_protected() for the writer-side loads (also under slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(), which run under RTNL. Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list traversal in teql_master_xmit(), so that readers either observe a fully linked list or are deferred until the in-flight mutation completes. The two early-return paths in teql_master_xmit() are updated to release the RCU-bh read-side critical section before returning, since leaving it held would disable BH on that CPU for good. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260628111229.669751-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b637d6b7266124f17445800695f3b8193a8615fb Author: Rosen Penev Date: Fri Jun 26 15:52:28 2026 -0700 net: gianfar: dispose irq mappings on probe failure and device removal [ Upstream commit dbf803bc4a8b0522c9a12560c20905a5952d1cb9 ] irq_of_parse_and_map() creates irqdomain mappings that should be balanced with irq_dispose_mapping(). The driver never called irq_dispose_mapping(), leaking mappings on probe failure and device removal. Fix by adding irq_dispose_mapping() in free_gfar_dev() and expanding its loop from priv->num_grps to MAXGROUPS so the error path also catches partially-initialized groups. All irqinfo pointers are pre-initialized to NULL in gfar_of_init(), making the NULL-guarded walk in free_gfar_dev() safe for every scenario. gfar_parse_group() itself is left as a simple parse function with no resource management; cleanup is centralized in the caller's error path. Assisted-by: opencode:big-pickle Fixes: b31a1d8b4151 ("gianfar: Convert gianfar to an of_platform_driver") Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260626225228.427392-1-rosenp@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 14b4cb78c3323d7a8b9031f47cd45b52855fd0c7 Author: Jiawen Wu Date: Fri Jun 26 17:25:30 2026 +0800 net: libwx: fix VMDQ mask for 1-queue mode [ Upstream commit 6ab752e0b59b825c127d5c86438bee1e8b1641ea ] In wx_set_vmdq_queues(), the VMDQ mask was not set for the devices not supporting WX_FLAG_MULTI_64_FUNC, i.e., NGBE devices. A mask of 0 causes __ALIGN_MASK(1, ~vmdq->mask) to return 0, which incorrectly sets q_per_pool to 0 in wx_write_qde(). Fix the VMDQ 1-queue mask to 0x7F then ensures that __ALIGN_MASK(1, ~0x7F) correctly evaluates to 1. Fixes: c52d4b898901 ("net: libwx: Redesign flow when sriov is enabled") Signed-off-by: Jiawen Wu Reviewed-by: Larysa Zaremba Link: https://patch.msgid.link/161F704D2C983E2C+20260626092530.551028-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2381bf3f484e8e4fd89a225445872ec14e036ab5 Author: Petr Wozniak Date: Sat Jun 27 19:32:41 2026 +0200 net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy [ Upstream commit 8f31efff9206f9f0adb853cad6916086aac4d5ef ] sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(), a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy() only unregisters the bus and clears sfp->i2c_mii without calling mdiobus_free(). As the only reference to the bus is then cleared, the struct mii_bus is leaked. This is hit whenever a copper/RollBall SFP module that instantiated an MDIO bus is removed: sfp_sm_main() takes the global teardown path and calls sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees sfp->i2c_mii directly, which is why the leak only triggered on module hot-removal and not on unbind. Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in sfp_i2c_mdiobus_create(). Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release") Signed-off-by: Petr Wozniak Reviewed-by: Maxime Chevallier Reviewed-by: Larysa Zaremba Link: https://patch.msgid.link/312bde8176fc429aa89524e3be250137f034ba84.1782581445.git.petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ef79fa3860e644c8de7834fa7300e1c58f38862 Author: Xiang Mei Date: Sat Jun 27 13:53:53 2026 -0700 usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() [ Upstream commit 8ff7f2a6da4fccaa5cc9be7251a24e71e29fbd1a ] genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. skb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected. Fixes: 47ee3051c856 ("[PATCH] USB: usbnet (5/9) module for genesys gl620a cables") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260627205353.4000788-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 110ccbd28c9444866fcc84ba96a2ad64fa6e95ae Author: Pengfei Zhang Date: Thu Jun 25 15:05:17 2026 +0800 ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump [ Upstream commit 9facb861dc6b9b9ea9793ef5032a9a826f7a4229 ] inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table. Fixes: 1b43af5480c3 ("[IPV6]: Increase number of possible routing tables to 2^32") Signed-off-by: Pengfei Zhang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260625070517.965597-1-zhangfeionline@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21f304c2aae46625e050c28d979f4b9d83faa85e Author: Jakub Kicinski Date: Thu Jun 25 09:05:08 2026 -0700 eth: fbnic: don't cache shinfo across skb realloc [ Upstream commit 62b68b774f06bf52e329f254f0199bc43d350ccf ] fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede Link: https://netdev.bots.linux.dev/logs/vmksft/fbnic-qemu-dbg/results/705762/15-uso-py/stderr Fixes: b0b0f52042ac ("eth: fbnic: support TCP segmentation offload") Reviewed-by: Alexander Duyck Link: https://patch.msgid.link/20260625160508.3327986-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb8a5afe6f1f8aa7f19c6dda23d277dd6ae5d9e1 Author: Guenter Roeck Date: Mon Jun 29 16:18:18 2026 -0700 hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-zero [ Upstream commit fe87b8dc67f1b2c64e76a66e78468c533d3c44ca ] Sashiko reports: In the aspeed-g6-pwm-tacho driver, the aspeed_tach_val_to_rpm() function calculates the fan RPM using the tachometer value. However, it does not check if the tachometer value is zero before performing the division. If the hardware reports a tachometer value of 0 (which can happen due to an extremely fast pulse, a stuck edge, or a hardware glitch), the calculated tach_div evaluates to 0. The subsequent call to do_div() with tach_div as the divisor triggers a divide-by-zero exception, leading to a kernel panic. Check the divisor against zero to fix the problem. Fixes: 7e1449cd15d1 ("hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach") Cc: Billy Tsai Reported-by: Sashiko Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b0ff6b6ae9c5183ef701ece7016698bde5a5bfba Author: Guenter Roeck Date: Mon Jun 29 16:08:00 2026 -0700 hwmon: (pmbus) Fix passing events to regulator core [ Upstream commit 9ef7dacd44216bf5ea05c8aef49eba4d145f4047 ] Sashiko reports: Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex") introduced a worker to batch regulator events over time using atomic_or(). The delayed worker then passes the combined bitmask unmodified to regulator_notifier_call_chain(). The core regulator subsystem's regulator_handle_critical() function evaluates the event parameter using a strict switch statement. If multiple distinct faults occur before the worker runs (e.g., REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined bitmask fails to match any case. This leaves the reason as NULL and completely bypasses the critical hw_protection_trigger(). Fix the problem by passing events bit by bit to the regulator event handler. Reported-by: Sashiko Fixes: 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 93b96e723bdcba6172a5814262be875abcc5d269 Author: Matti Vaittinen Date: Fri Jun 26 10:22:04 2026 +0300 hwmon: adm1275: Prevent reading uninitialized stack [ Upstream commit 553f9517813912a5ab661af5504485d96824a61c ] While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like "adm12", checking it against "adm1275" up to the length of "adm1275" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array. Signed-off-by: Matti Vaittinen Fixes: 87102808d039 ("hwmon: (pmbus/adm1275) Validate device ID") Link: https://lore.kernel.org/r/c8ad38e0cdb347261c6245de2b7965e747f28d22.1782458224.git.mazziesaccount@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 65e7e2b8d71b418439ebc68e80ed3e5a325375d6 Author: Lizhi Hou Date: Wed Jun 10 22:51:50 2026 -0700 accel/amdxdna: Fix iommu domain lifetime race during device removal [ Upstream commit b4a0500fdf6e61a6c5f92ff2e61bc91578075803 ] When force_iova mode is enabled, amdxdna_remove() frees xdna->domain. If amdxdna_gem_obj_free() is called after device removal, it may attempt to access xdna->domain, resulting in a use-after-free. Fix the race by adding freeing xdna->domain as a managed release action, so its lifetime is managed by DRM and remains valid until all managed resources are released. Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260611055150.3070216-3-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 5bd0d47640395f8a8c34446b62d1781b88869dfa Author: Abdurrahman Hussain Date: Sat Jun 20 00:50:37 2026 -0700 hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid() [ Upstream commit 828cd614e2af053ca5e1d6da767bbd8a1b5cabfb ] pmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the vrm_version configured by the driver, while pmbus_reg2data_vid() already switched on it. Any driver that selects a non-VR11 VID mode and exposes a regulator (or hwmon vout setter) sent dangerously wrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the chip interprets as 1080 mV. Mirror pmbus_reg2data_vid() so writes round-trip with reads. Signed-off-by: Abdurrahman Hussain Assisted-by: Claude:claude-opus-4-7 [Claude Code] Link: https://lore.kernel.org/r/20260620-pmbus-data2reg-vid-v1-1-5518030432c4@nexthop.ai Fixes: 068c227056b92 ("hwmon: (pmbus) Add support for VR12") Fixes: d4977c083aeb2 ("hwmon: (pmbus) Add support for Intel VID protocol VR13") Fixes: 9d72340b6ade9 ("hwmon: (pmbus/core) Add support for Intel IMVP9 and AMD 6.25mV modes") Fixes: 969a4ec86ca5f ("hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 492d0c8f78d425d23b7e09e0141e0465ffc484a0 Author: Luca Weiss Date: Tue May 26 17:03:05 2026 +0200 ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280 [ Upstream commit 0773610eef71c30df3cb4c113c8215625d2a7c23 ] According to both the static definition in downstream... yupik-audio-overlay.dtsi: qcom,bolero-version = <4>; #define BOLERO_VERSION_2_0 0x0004) and the runtime detection: CDC_VA_TOP_CSR_CORE_ID_0=0x1 CDC_VA_TOP_CSR_CORE_ID_1=0xf SC7280 has LPASS Codec Version 2.0 and not, as declared with sm8250_va_data LPASS_CODEC_VERSION_1_0. Create new va_macro_data with .version not set to use the runtime detection and correctly get .version = LPASS_CODEC_VERSION_2_0. Fixes: 77212f300bfd ("ASoC: codecs: lpass-va-macro: set the default codec version for sm8250") Signed-off-by: Luca Weiss Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260526-sc7280-va-macro-2-0-v1-1-2c1b572fa388@fairphone.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f3ed7454024415bc626919f7eb1fa799c72fba5c Author: Kyle Hendry Date: Sun Jun 21 11:47:02 2026 -0700 MIPS: mm: Add check for highmem before removing memory block [ Upstream commit 6d5fbecd0213489bc4de71a0da194d18e654fd6e ] If a device has less physical memory than the highmem threshold bootmem_init() doesn't set highstart_pfn. This results in highmem_init() wrongly disabling the entire memory range if the cpu doesn't support highmem. Add a check that highstart_pfn is non zero before removing the highmem block. Fixes: f171b55f1441 ("mips: fix HIGHMEM initialization") Signed-off-by: Kyle Hendry Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 3aca736e177f46e81ece986fa0676809d03a1a71 Author: Maciej W. Rozycki Date: Wed May 6 23:43:00 2026 +0100 MIPS: DEC: Ensure RTC platform device deregistration upon failure [ Upstream commit eacaf5ae747f7dead6cc268de17a7382d79031fc ] Switch RTC platform device registration from platform_device_register() to platform_add_devices() so as to make sure any failure will result in automatic device unregistration. Fixes: fae67ad43114 ("arch/mips/dec: switch DECstation systems to rtc-cmos") Signed-off-by: Maciej W. Rozycki Acked-by: Thomas Bogendoerfer Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 062bcbf8d1f1051fdeb20b94920031b0e2cb95a2 Author: Xin Long Date: Wed Jun 24 18:53:12 2026 -0400 sctp: add INIT verification after cookie unpacking [ Upstream commit 414c5447fe6a200613dd46d7fdc8454622076cb1 ] In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Link: https://patch.msgid.link/ebcbbac574815b0850f371b4bdb02f2e602b94d3.1782341592.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7776052bb2325a30e12bed640b1179e7d7e4515 Author: Yousef Alhouseen Date: Thu Jun 25 16:23:54 2026 +0200 sctp: fix SCTP_RESET_STREAMS stream list length limit [ Upstream commit 2b9f5ef534184bd81b8a4772780626c40eed1fd5 ] SCTP_RESET_STREAMS carries a flexible array of u16 stream IDs, but the optlen clamps treat USHRT_MAX as a byte count and then multiply sizeof(__u16) by the fixed header size. That caps the copied and validated option buffer at about 64 KiB, which rejects valid requests containing more than about half of the u16 stream ID range. Use struct_size_t() for the maximum struct sctp_reset_streams layout instead, so the bound matches the flexible array described by srs_number_streams. Fixes: 5960cefab9df ("sctp: add a ceiling to optlen in some sockopts") Acked-by: Xin Long Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260625142354.2600-1-alhouseenyousef@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d22829101ab675607ad6c3d420fb3ab875f46bbb Author: Wei Fang Date: Fri Jun 26 15:32:44 2026 +0800 net: enetc: check the number of BDs needed for xdp_frame [ Upstream commit 555c5475e787802eeae0d2b91c2f66c330db2767 ] The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds. Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260626073244.2168214-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d46ab395803f162cdc50e8d346e5f1a4e766771 Author: Matvey Kovalev Date: Tue Jun 23 17:45:54 2026 +0300 qede: fix out-of-bounds check for cqe->len_list[] [ Upstream commit f9ba47fce5932c15891c89c60e76dfaca919cb8d ] Move index check before element access. Fixes: 896f1a2493b5 ("net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()") Signed-off-by: Matvey Kovalev Link: https://patch.msgid.link/20260623144602.3521-1-matvey.kovalev@ispras.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c9961336aa5ff83092f23e33ee86666a9dbd1b2a Author: Nuoqi Gui Date: Tue Jun 23 18:32:31 2026 +0800 seg6: validate SRH length before reading fixed fields [ Upstream commit a75d99f46bf21b45965ce39c5cfb3b8bb5ffb1aa ] seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust. Fixes: fe94cc290f53 ("bpf: Add IPv6 Segment Routing helpers") Signed-off-by: Nuoqi Gui Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260623-f01-17-seg6-srh-len-v2-1-2edc40e9e3e1@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e1fc4b00b96de78cc781b6489bf44563c667a6f7 Author: Corey Leavitt Date: Wed Jun 24 22:40:16 2026 +0200 net: pse-pd: scope pse_control regulator handle to kref lifetime [ Upstream commit 16759757c4d28e958fd5a5a1fe0f86828872f28d ] __pse_control_release() drops psec->ps via devm_regulator_put(), which only succeeds if the devres entry added by the matching devm_regulator_get_exclusive() is still present on pcdev->dev at the time the pse_control's kref hits zero. That assumption does not hold when the controller is unbound while a pse_control still has consumers: pcdev->dev's devres list is released LIFO, so every per-attach regulator-GET devres runs (and regulator_put()s the underlying regulator) before pse_controller_unregister() itself is invoked. Any later pse_control_put() from that unbind path then reads psec->ps as a dangling pointer inside devm_regulator_put() and WARNs at drivers/regulator/devres.c:232 (devres_release() fails to find the already-released match). The pse_control's consumer handle is logically scoped to the pse_control's refcount, not to pcdev->dev's devres lifetime. Switch to the plain regulator_get_exclusive() / regulator_put() pair so the regulator put in __pse_control_release() no longer depends on the controller's devres still being present. No change to the regulator-framework-visible refcount or lifetime of the underlying regulator: a single get paired with a single put. The existing devm_regulator_register() for the per-PI rails is unchanged (those ARE correctly scoped to the controller's lifetime). This addresses only the regulator handle. The same unbind-while-held scenario also leaves __pse_control_release() reading psec->pcdev->pi[] and psec->pcdev->owner after pse_controller_unregister() has freed pcdev->pi, because the controller does not drain its outstanding pse_control references on unregister. That wider pse_control vs pcdev lifetime problem pre-dates this change and is addressed by the PSE controller notifier series, which drains phydev->psec on PSE_UNREGISTERED before pcdev->pi is freed. Link: https://lore.kernel.org/netdev/20260620112440.1734404-1-github@szelinsky.de/ Fixes: d83e13761d5b ("net: pse-pd: Use regulator framework within PSE framework") Signed-off-by: Corey Leavitt Acked-by: Kory Maincent Signed-off-by: Carlo Szelinsky Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260624204017.2752934-1-github@szelinsky.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 151db2b5474411ac33b1875e7321ce97755af262 Author: Pengpeng Hou Date: Wed Jun 24 21:18:28 2026 +0800 gpio: htc-egpio: use managed gpiochip registration [ Upstream commit 17326db5f0ab4ec1901e75d052b5ebef486b467f ] egpio_probe() registers each nested gpio_chip with gpiochip_add_data() but ignores the return value. If one registration fails, probe still returns success even though one of the chips was not published to gpiolib. Use devm_gpiochip_add_data() and fail probe if any chip registration fails. This lets devres unwind already registered chips and prevents the driver from publishing a partially initialized device. Fixes: a1635b8fe59d ("[ARM] 4947/1: htc-egpio, a driver for GPIO/IRQ expanders with fixed input/output pins") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260624131828.94139-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 537e75aeb9cc4c4d93533815434d3d8fe3999c90 Author: Pengpeng Hou Date: Wed Jun 24 21:16:45 2026 +0800 gpio: mvebu: fail probe if gpiochip registration fails [ Upstream commit 479e91fc92416a4d54d2b3150aa1e4550d9cc759 ] mvebu_gpio_probe() registers the GPIO chip with devm_gpiochip_add_data() but ignores the return value. If registration fails, probe continues and leaves later code operating on a GPIO chip that was never published to gpiolib. Return the registration error so the device fails probe cleanly. Fixes: fefe7b092345 ("gpio: introduce gpio-mvebu driver for Marvell SoCs") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260624131645.86884-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit d8df91756890de058646597367507b239a6d2025 Author: KaFai Wan Date: Wed Jun 24 20:35:35 2026 +0800 bpf: Fix insn_aux_data leak on verifier err_free_env path [ Upstream commit 26490a375cb9be9bac96b5171610fd85ca6c2305 ] When bpf_check() allocates env->insn_aux_data successfully but later fails to allocate env->succ, it jumps directly to err_free_env. The existing vfree(env->insn_aux_data) sits before the err_free_env label, so that direct jump bypasses it and leaks insn_aux_data. Move vfree(env->insn_aux_data) into err_free_env so all early and late exit paths release it consistently. Fixes: 2f69c5685427 ("bpf: make bpf_insn_successors to return a pointer") Signed-off-by: KaFai Wan Reviewed-by: Anton Protopopov Link: https://lore.kernel.org/r/20260624123536.114757-1-kafai.wan@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1c53d16b174dd9e02243fc0e85089e2aa6a0d21a Author: Nuoqi Gui Date: Tue Jun 23 18:43:38 2026 +0800 bpf: Mask pseudo pointer values in verifier logs [ Upstream commit 72a85e9464a5332fb2cd7efd26d9295275ceda2d ] print_bpf_insn() masks ldimm64 immediates for pointer-bearing pseudo sources when pointer leaks are not allowed, but the mask only covers BPF_PSEUDO_MAP_FD and BPF_PSEUDO_MAP_VALUE. BPF_PSEUDO_MAP_IDX, BPF_PSEUDO_MAP_IDX_VALUE, and BPF_PSEUDO_BTF_ID can also be resolved to kernel pointer values before the verifier log prints the instruction. Include them in the existing pointer classification so the log prints 0x0 instead of the rewritten address. Fixes: 4976b718c355 ("bpf: Introduce pseudo_btf_id") Fixes: 387544bfa291 ("bpf: Introduce fd_idx") Signed-off-by: Nuoqi Gui Link: https://lore.kernel.org/r/20260623-f01-13-pseudo-btf-id-cap-bpf-v2-1-a190ebb8f3e2@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Acked-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 5c907c11615fd07cd65defcb7a0cefbe547c047e Author: Samuel Holland Date: Wed Jun 24 19:31:48 2026 +0800 riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI [ Upstream commit c4c7756a81b5baef286bf9be1ea404f3e4dd7a3c ] call_on_irq_stack() uses struct member offsets to set up its link in the frame record list. On riscv32, struct stackframe is the wrong size to maintain stack pointer alignment, so STACKFRAME_SIZE_ON_STACK includes padding. However, the ABI requires the frame record to be placed immediately below the address stored in s0, so the padding must come before the struct members. Fix the layout by making STACKFRAME_FP and STACKFRAME_RA the negative offsets from s0, instead of the positive offsets from sp. Fixes: 82982fdd5133 ("riscv: Deduplicate IRQ stack switching") Signed-off-by: Samuel Holland Reviewed-by: Matthew Bystrin Signed-off-by: Rui Qi Link: https://lore.kernel.org/all/20240530001733.1407654-2-samuel.holland@sifive.com/ Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260624113148.3723541-1-qirui.001@bytedance.com [pjw@kernel.org: cleaned up the patch tags and added Matthew's Reviewed-by] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit d1a22906727b1a2ce98600bde0171d78e66e114b Author: Yicong Yang Date: Thu Jun 25 17:47:02 2026 +0800 ACPI: RIMT: Only defer the IOMMU configuration in init stage [ Upstream commit b8f62414fa05144924257db283c5c35f74d21121 ] The IOMMU configuration will be deferred if the IOMMU driver isn't probed by the time. Make this deferral only in the initialization stage with driver_deferred_probe_check_state(). Otherwise the devices depends on IOMMU will be deferred forever in case the IOMMU device probe failed or it doesn't appear in the ACPI namespace. Fixes: 8f7729552582 ("ACPI: RISC-V: Add support for RIMT") Signed-off-by: Yicong Yang Link: https://patch.msgid.link/20260625094702.11558-1-yang.yicong@picoheart.com [pjw@kernel.org: added Fixes line] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit c637ec6a45925e962c867b717f4f23a2c5c4508d Author: Pengpeng Hou Date: Tue Jun 23 21:58:34 2026 +0800 spi: sh-msiof: abort transfers when reset times out [ Upstream commit 6dbaa4d288432c697cea47028480481b8b29bd6a ] sh_msiof_spi_reset_regs() asserts TX/RX reset and polls until the reset bits clear, but the poll result is ignored. sh_msiof_transfer_one() can therefore continue programming a transfer after the controller did not leave reset. Return the reset poll result from the helper and abort the transfer on timeout, matching the existing transfer path's error-return style. Fixes: fedd6940682a ("spi: sh-msiof: Add reset of registers before starting transfer") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623135834.55442-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b2fa801be46d59c62904dbc5b0b128305fdf76eb Author: Martin Kaiser Date: Thu Jun 25 08:34:45 2026 +0900 tracing: probes: fix typo in a log message [ Upstream commit 72c8646956ffc8050bb8be5988a0f28fc37e1ac4 ] Fix a typo ("Invalid $-variable") in a log message. Link: https://lore.kernel.org/all/20260507081041.885781-4-martin@kaiser.cx/ Fixes: ab105a4fb894 ("tracing: Use tracing error_log with probe events") Signed-off-by: Martin Kaiser Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 3ab06151ffcb8c3aeb8f78508658b6c0f05be932 Author: Jiaming Zhang Date: Thu Jun 25 21:49:33 2026 +0800 ALSA: FCP: Fix NULL pointer dereference in interface lookup [ Upstream commit e1e31e0ec8a609e17fd2e86b77bc00d9cbb24d7c ] A malformed USB device can provide a vendor-specific interface without any endpoint descriptors. fcp_find_fc_interface() currently selects the first vendor-specific interface and reads endpoint 0 from it, without checking whether the interface actually has any endpoints. When bNumEndpoints is zero, no endpoint array is allocated for the parsed alternate setting, so get_endpoint(..., 0) yields an invalid endpoint descriptor pointer. Dereferencing it through usb_endpoint_num() then triggers a NULL pointer dereference. Skip vendor-specific interfaces that do not have any endpoints. Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Reported-by: Jiaming Zhang Closes: https://lore.kernel.org/lkml/CANypQFb1EHj0xX8bA1WxSOSK-5xca6ZNKzOQcp12=s=puY7VFw@mail.gmail.com/ Signed-off-by: Jiaming Zhang Link: https://patch.msgid.link/20260625134933.425785-1-r772577952@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b4c34415b82b7d63607bbb991b84705d7f33ed9f Author: Shuaisong Yang Date: Wed Jun 24 22:13:19 2026 +0800 net: hns3: differentiate autoneg default values between copper and fiber [ Upstream commit d9d349c4e8a0acd73bac8baa3605443c0df5eb26 ] Fix a link loss issue during driver initialization on optical ports connected to forced-mode (non-autoneg) remote switches. Previously, during driver probe or initialization, hclge_configure() blindly hardcoded hdev->hw.mac.req_autoneg to AUTONEG_ENABLE for all media types. While this is necessary for copper (BASE-T) ports to establish a link, many high-speed optical (fiber) ports in data centers are connected to switches running in forced mode (fixed speed, autoneg disabled). Forcing autoneg on these optical ports during initialization causes a permanent link failure since the remote end refuses to respond to autoneg pulses. Fix this by implementing media-type differentiated initialization in hclge_init_ae_dev(). Copper ports continue to default to AUTONEG_ENABLE, while optical ports strictly inherit the preset autoneg status pre-configured by the firmware (hdev->hw.mac.autoneg), preserving native compatibility with forced-mode network environments. Fixes: 05eb60e9648c ("net: hns3: using user configure after hardware reset") Signed-off-by: Shuaisong Yang Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260624141319.271439-5-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 783dcef78cb05e16f7961c18a9ae22b1aeed057a Author: Shuaisong Yang Date: Wed Jun 24 22:13:18 2026 +0800 net: hns3: fix permanent link down deadlock after reset [ Upstream commit c711f6d1cee955e04d1cd1f76cd8abd024b27a72 ] Fix a critical race condition deadlock where the network interface remains permanently Link Down after a hardware reset under specific ethtool sequences. This issue exclusively manifests in firmware-controlled PHY topologies where the driver relies on the IMP firmware to arbitrate link parameters. Standard devices driven by the kernel's native PHY_LIB are unaffected. The deadlock occurs via the following path: 1. User disables autoneg and forces an unmatched speed, forcing link down: `ethtool -s ethx autoneg off speed 10 duplex full` 2. User re-enables autoneg: `ethtool -s ethx autoneg on`. The netdev stack passes cmd->base.speed as SPEED_UNKNOWN (0xffffffff). 3. Driver saves req_autoneg=1, but before the interface can link up, a hardware reset is triggered. 4. During reset recovery, MAC init reads the un-synchronized runtime state mac.autoneg (which is still 0/OFF), misinterprets it as forced mode, and pushes the cached SPEED_UNKNOWN into the hardware registers, causing the MAC firmware state machine to freeze. Meanwhile, PHY init reads req_autoneg=1 and enables PHY autoneg. Since the MAC is frozen with 0xffffffff and PHY is running autoneg, they mismatch permanently. Fix this by: 1. Intercepting SPEED_UNKNOWN/DUPLEX_UNKNOWN in hclge_set_phy_link_ksettings() and hclge_cfg_mac_speed_dup_h() to prevent it from corrupting the driver's cached valid configuration. 2. Save req_autoneg in hclge_set_autoneg(). 3. Aligning the state judgment in hclge_set_autoneg_speed_dup() to use req_autoneg instead of the un-synchronized runtime mac.autoneg, ensuring both MAC and PHY consistently enter the autoneg branch to eliminate configuration discrepancies during reset recovery. Fixes: 05eb60e9648c ("net: hns3: using user configure after hardware reset") Signed-off-by: Shuaisong Yang Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260624141319.271439-4-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 99f6a07add50feaf141ad28225c19fab7e2ef54f Author: Shuaisong Yang Date: Wed Jun 24 22:13:17 2026 +0800 net: hns3: refactor MAC autoneg and speed configuration [ Upstream commit c01f6e6bdc1ccd21b2d07d23f50b82437b8cbf88 ] Extract the MAC autoneg and speed/duplex/lane configuration logic out of hclge_mac_init() and encapsulate it into a new dedicated helper function hclge_set_autoneg_speed_dup(). In the init path (hclge_init_ae_dev), this helper is now called after hclge_update_port_info() so that firmware-reported autoneg values are already populated before applying the link configuration. Introduce a separate req_lane_num field in struct hclge_mac to isolate the user-requested lane count from mac.lane_num, which firmware may overwrite via hclge_get_sfp_info() with stale values from a prior link lifecycle (e.g., lane_num=4 from 100G). During probe, req_lane_num is initialized to 0, which instructs firmware to auto-select the correct lane count for the current speed, rather than reusing the firmware- reported mac.lane_num that may be inconsistent with the target speed. This prevents probe failures from mismatched (speed, lane_num) pairs. In the reset path (hclge_reset_ae_dev), it runs immediately after hclge_mac_init(), using the previously cached req_* values to restore the link without re-querying firmware. Signed-off-by: Shuaisong Yang Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260624141319.271439-3-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Stable-dep-of: c711f6d1cee9 ("net: hns3: fix permanent link down deadlock after reset") Signed-off-by: Sasha Levin commit ac04c2c833dd872cfae9539536b4d9bcc1ab064b Author: Shuaisong Yang Date: Wed Jun 24 22:13:16 2026 +0800 net: hns3: unify copper port ksettings configuration path [ Upstream commit d77e98f8b2b382b06be7f17e482480dd8c4c5046 ] Refactor hns3_set_link_ksettings() and hclge_set_phy_link_ksettings() to unify the configuration path for copper ports. Previously, netdevs with a native kernel phy attached bypassed the main MAC parameter caching logic and returned early via phy_ethtool_ksettings_set(). This prevented the driver from updating hdev->hw.mac.req_xxx variables for kernel PHY setups, leaving them out-of-sync during reset recovery. Clean this up by routing all copper port configurations through ops->set_phy_link_ksettings(), and perform driver-level or kernel-level PHY arbitration inside hclge_set_phy_link_ksettings() via hnae3_dev_phy_imp_supported(). This ensures that the user's intended link profiles (req_speed, req_duplex, req_autoneg) are uniformly recorded across all copper and fiber deployment topologies, laying the groundwork for stable reset recovery. For copper ports where neither IMP firmware nor a kernel PHY is available (e.g. PHY_INEXISTENT), hclge_set_phy_link_ksettings() returns -ENODEV. In hns3_set_link_ksettings(), this is caught so the configuration falls through to the existing MAC-level path (check_ksettings_param -> cfg_mac_speed_dup_h), preserving compatibility with PHY-less copper deployments. Signed-off-by: Shuaisong Yang Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260624141319.271439-2-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Stable-dep-of: c711f6d1cee9 ("net: hns3: fix permanent link down deadlock after reset") Signed-off-by: Sasha Levin commit 9715ea1ceab786526682d416bacff5876f4a375b Author: Nirmoy Das Date: Wed Jun 24 06:44:16 2026 -0700 selftests: tls: size splice_short pipe by page size [ Upstream commit 3e52f56875c6fafee619b5c2b4ded25f2efbd2ec ] splice_short grows its pipe with (MAX_FRAGS + 1) * 0x1000 so it can queue one short vmsplice() buffer for each fragment before draining the pipe. That assumes 4K pipe buffers. On 64K-page kernels the request is rounded to 262144 bytes, which provides only four pipe buffers. The fifth one-byte vmsplice() blocks in pipe_wait_writable and the test times out before it reaches the TLS path. Request enough bytes for the same number of pipe buffers using the runtime page size, and assert that the kernel granted at least that much. If an unprivileged run cannot raise the pipe above the system pipe-max-size limit, skip the test because it cannot exercise the intended path. Fixes: 3667e9b442b9 ("selftests: tls: add test for short splice due to full skmsg") Signed-off-by: Nirmoy Das Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260624134416.3235403-1-nirmoyd@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 522d1d950b9e3b68190a6de7534827c8dccedb73 Author: Eric Dumazet Date: Tue Jun 23 17:30:30 2026 +0000 tipc: avoid busy looping in tipc_exit_net() [ Upstream commit c1481c94e74c955e0448ddf46b8615a44d840c1e ] Blamed commit introduced a busy-wait loop in tipc_exit_net() to wait for pending UDP bearer cleanup works to complete: while (atomic_read(&tn->wq_count)) cond_resched(); This loop can busy-wait for a long time if cond_resched() is a NOP. This typically happens if the netns exit is executed by a high priority task, or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In such cases, it wastes CPU cycles and can lead to soft lockups. Fix this by replacing the busy loop with wait_var_event(), allowing the thread to sleep properly until the work queue count reaches zero. Accordingly, update cleanup_bearer() to use atomic_dec_and_test() and wake_up_var() to wake up the waiter when the count drops to zero. This uses the global wait queue hash table, avoiding the need to bloat struct tipc_net with a wait_queue_head_t. The atomic_dec_and_test() provides the necessary memory barrier to ensure the wakeup is not missed. Fixes: 04c26faa51d1 ("tipc: wait and exit until all work queues are done") Signed-off-by: Eric Dumazet Cc: Jon Maloy Cc: tipc-discussion@lists.sourceforge.net Reviewed-by: Xin Long Link: https://patch.msgid.link/20260623173030.2925059-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c8393eefa3cadf4ca0b61119ad1321aa32d3c8c Author: Eric Dumazet Date: Tue Jun 23 17:30:29 2026 +0000 tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy() [ Upstream commit 7116764ca53ff529335d7ab7c364a69f094b23a5 ] TIPC UDP media bearer teardown calls dst_cache_destroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters) to finish: static void cleanup_bearer(struct work_struct *work) { ... list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) { dst_cache_destroy(&rcast->dst_cache); list_del_rcu(&rcast->list); kfree_rcu(rcast, rcu); } ... dst_cache_destroy(&ub->rcast.dst_cache); udp_tunnel_sock_release(ub->sk); synchronize_net(); ... } This is highly buggy because dst_cache_destroy() immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any synchronization. If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another CPU under RCU protection, it can call dst_cache_get() concurrently, leading to: 1. Use-After-Free on the per-CPU cache pointer itself (crash). 2. "rcuref - imbalanced put()" warning if it attempts to release a dst that was concurrently released by dst_cache_destroy(). Furthermore, calling kfree(ub) immediately after synchronize_net() without closing the socket first (or waiting after closing it) leaves a window where a concurrent receiver (tipc_udp_recv()) could start after synchronize_net(), access ub, and suffer a UAF when kfree(ub) runs. To fix this, we must defer dst_cache_destroy() and kfree(ub) until after we have ensured that no more readers can see the bearer/socket and all existing readers have finished: 1. Defer rcast entry destruction (both dst_cache_destroy() and kfree()) to an RCU callback using call_rcu_hurry(). Using call_rcu_hurry() ensures the dst entries are released quickly. 2. Release the bearer socket using udp_tunnel_sock_release() (stops new receive readers). 3. Call synchronize_net() to wait for all outstanding RCU readers (both transmit and receive) to finish. 4. Now that it is safe, call dst_cache_destroy() on the main bearer cache, and free ub. Note: 3) and 4) can be changed later in net-next to also use call_rcu_hurry() and get rid of the synchronize_net() latency. Fixes: e9c1a793210f ("tipc: add dst_cache support for udp media") Reported-by: syzbot+e14bc5d4942756023b77@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a396a66.52ae72c2.136ac7.0003.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Jon Maloy Cc: tipc-discussion@lists.sourceforge.net Reviewed-by: Xin Long Link: https://patch.msgid.link/20260623173030.2925059-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: c1481c94e74c ("tipc: avoid busy looping in tipc_exit_net()") Signed-off-by: Sasha Levin commit 46d8d5b02f897903a820f007c645c229d06bace5 Author: Kuniyuki Iwashima Date: Sat May 2 03:13:07 2026 +0000 tipc: Store struct sock in struct udp_bearer. [ Upstream commit 1ae552c7b6658c23fba8e964e687785297078880 ] tipc udp_bearer does not need to access struct socket itself in the fast path; it only reads struct sock, and struct socket is only used for tunnel setup and teardown. Let's store struct sock directly in struct udp_bearer. Note that cleanup_bearer() calls synchronize_net() after udp_tunnel_sock_release(), so udp_bearer is not freed until inflight fast paths finish. Note also that synchronize_rcu() is added in the error path of tipc_udp_enable() since udp_bearer will be kfree()d immediately once we remove synchronize_rcu() in udp_tunnel_sock_release(). This can be later converted to kfree_rcu(). Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-15-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: c1481c94e74c ("tipc: avoid busy looping in tipc_exit_net()") Signed-off-by: Sasha Levin commit 80e9adfed05d687a984b18d2f6ab2ee2bba370cf Author: Kuniyuki Iwashima Date: Sat May 2 03:12:55 2026 +0000 udp_tunnel: Pass struct sock to setup_udp_tunnel_sock(). [ Upstream commit 2cba193628fe523cee6dd61938db2c4563ce15a9 ] None of the udp_tunnel users need struct socket in their fast paths; it is only used for tunnel setup / teardown. Even setup_udp_tunnel_sock() does not need struct socket. Let's change setup_udp_tunnel_sock() to take struct sock instead of struct socket. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: c1481c94e74c ("tipc: avoid busy looping in tipc_exit_net()") Signed-off-by: Sasha Levin commit ea0eb61029e08aa44d70f2ad9a5c5bd984a1efbe Author: Kuniyuki Iwashima Date: Sat May 2 03:12:54 2026 +0000 udp_tunnel: Pass struct sock to udp_tunnel_sock_release(). [ Upstream commit 944bfc1b1c6fe9417668006aae7124886bcca038 ] None of the udp_tunnel users need struct socket in their fast paths; it is only used for tunnel setup / teardown. While the UDP tunnel interface accepts struct socket, this encourages users to store the pointer unnecessarily. This leads to extra dereferences when accessing struct sock fields (e.g., sk->sk_user_data instead of sock->sk->sk_user_data). Furthermore, these dereferences necessitate synchronize_rcu() in udp_tunnel_sock_release() to protect the fast paths from sock_orphan() setting sk->sk_socket to NULL. This overhead can be avoided if users store the struct sock pointer directly in their private structures. As a prep, let's change udp_tunnel_sock_release() to take struct sock instead of struct socket. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: c1481c94e74c ("tipc: avoid busy looping in tipc_exit_net()") Signed-off-by: Sasha Levin commit cd37bcb67f909a8683cc8c38a63ac7367a7f6161 Author: Wei Fang Date: Wed Jun 24 15:27:26 2026 +0800 net: enetc: fix potential divide-by-zero when num_vsi is zero [ Upstream commit 5da65537792b68b6052ffcab65e04c27aea6dfe4 ] For i.MX94 series, all the standalone ENETCs do not support SR-IOV, so pf->caps.num_vsi is zero. This leads to a divide-by-zero in enetc4_default_rings_allocation() when distributing rings among PF and VFs. Division by zero is undefined behavior in C. On ARM64, the UDIV/SDIV instructions silently return zero rather than raising an exception, so the issue does not cause a visible crash. However, relying on this behavior is incorrect and poses a cross-platform compatibility risk. Add an explicit check for num_vsi == 0 and return early after the PF's rings have been configured. Fixes: 2d673b0e2f8d ("net: enetc: add standalone ENETC support for i.MX94") Signed-off-by: Wei Fang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260624072726.1238903-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2542ce01d8114931657cdba55a5d17c3589ef06f Author: Rob Herring (Arm) Date: Wed Jun 24 10:02:50 2026 -0500 dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback [ Upstream commit 14eb1d2c03b38ce3427f299967f7a4d97ebff4c2 ] Fix the Micrel PHY in the example which shouldn't have the fallback "ethernet-phy-ieee802.3-c22" compatible: Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 \ (ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long from schema $id: http://devicetree.org/schemas/net/micrel.yaml Signed-off-by: Rob Herring (Arm) Reviewed-by: Andrew Lunn Acked-by: Conor Dooley Acked-by: Niklas Söderlund Fixes: 37a2fce09001 ("dt-bindings: sh_eth convert bindings to json-schema") Link: https://patch.msgid.link/20260624150250.131966-2-robh@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54292b167466cdf42176b7b6f01da66c184deb12 Author: Eric Dumazet Date: Thu Jun 25 06:59:36 2026 +0000 net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync [ Upstream commit ecf69d4b43370c587e48d4d70289dbdb7e039d4d ] Yue Sun reported a use-after-free and debugobjects warning in udp_tunnel_nic_device_sync_work() during concurrent device operations. The workqueue core clears the internal pending bit before invoking the worker. At that point, a concurrent thread can queue the work again. When the already running worker eventually clears the work_pending flag to 0, it mistakenly clears the flag for the newly queued instance. udp_tunnel_nic_unregister() then observes work_pending as 0 and frees the structure while the second work item is still active in the queue, leading to UAF. Fix this by returning early in udp_tunnel_nic_device_sync() if work_pending is already set, preventing redundant work queueing. Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure") Reported-by: Yue Sun Suggested-by: Jakub Kicinski Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260625065938.654652-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5fafece300c26ca1ba563e4cc35dcd84e86464f Author: Shengjiu Wang Date: Thu Jun 25 18:24:16 2026 +0800 ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count [ Upstream commit cf6f56990ea21172e085f0588e5bbf2089ce8f58 ] The back-end consumes data in units of the number of channels. When the maxburst value is not evenly divisible by the channel count, the DMA transfer length does not align with the FIFO frame boundary, causing wrong data to be copied and audible noise at the end of the stream. This is specific to eDMA: eDMA only responds to DMA requests from the back-end, whereas SDMA handles requests from both the front-end and the back-end and is not affected. For eDMA, when the back-end maxburst is not evenly divisible by the channel count, align it to the nearest valid boundary: - If maxburst >= channel count, override to the channel count so each transfer corresponds to exactly one audio frame. - If maxburst < channel count, override to 1 to avoid partial-frame transfers. Retain the original maxburst for SDMA or when it already aligns with the channel count. Fixes: c05f10f28ef6 ("ASoC: fsl_asrc: Add support for imx8qm & imx8qxp") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260625102416.424911-1-shengjiu.wang@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0ddb9dcabf0b72b83f62f67c3d959af344a684f7 Author: Tiezhu Yang Date: Thu Jun 25 13:03:53 2026 +0800 LoongArch: BPF: Fix off-by-one error in tail call [ Upstream commit 0379d10f09bc21ba739636796669dfb4936172a3 ] The current code updates the tail call counter (TCC) using a pre-increment approach, it stores the incremented value back to memory before performing any boundary or target validation checks. This causes two major issues: 1. When a tail call fails because the target program is NULL, the TCC is incorrectly incremented and saved in memory anyway. 2. This dummy increment implicitly consumes one slot of the allowed tail call budget. As a result, the subsequent loop reaches the maximum limit prematurely, leading to a test failure where the actual loop count is 32 instead of the expected 33. Fix this by deferring the counter update. Change the branch condition to BPF_JSGE (greater or equal) so that we check the boundary first. The TCC is only incremented and stored back to memory after the boundary check and the NULL-target check both pass. Before: $ sudo ./test_progs -t tailcalls/tailcall_3 ... test_tailcall_count:FAIL:tailcall count unexpected tailcall count: actual 32 != expected 33 ... #465/3 tailcalls/tailcall_3:FAIL #465 tailcalls:FAIL After: $ sudo ./test_progs -t tailcalls/tailcall_3 #465/3 tailcalls/tailcall_3:OK #465 tailcalls:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED Fixes: c0fcc955ff82 ("LoongArch: BPF: Fix the tailcall hierarchy") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 09068613dd0dfbfacf50ff297b900be6ba500c50 Author: Tiezhu Yang Date: Thu Jun 25 13:03:53 2026 +0800 LoongArch: BPF: Fix outdated tail call comments [ Upstream commit 25d9127bb0e27275d55a5b3d0fd30b04bafffd5a ] The current LoongArch BPF JIT implementation hardcodes the number of prologue instructions skipped during a tail call as a magic number '7' in the jirl instruction. However, the accompanying comment explaining this offset is completely outdated. It inaccurately states that only a single TCC initialization instruction is bypassed, but in reality, multiple setup slots are skipped, so fix these outdated comments in __build_epilogue(). While at it, refine the comments in build_prologue() to describe the skipped setup slots (RA saving, fentry nops, and the TCC register slot) using proper dynamic tracing context. Also, remove the magic number '7' by introducing descriptive macros to formally define the prologue layout and make the tail call jump offset self-documenting. Fixes: 61319d15a560 ("LoongArch: BPF: Adjust the jump offset of tail calls") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit ee79d03aafb517fe2eab5782816b49ffd65a6d16 Author: 谢致邦 (XIE Zhibang) Date: Thu Jun 25 13:03:49 2026 +0800 LoongArch: Move struct kimage forward declaration before use [ Upstream commit d4e58d2c21d94282d512979dfa7e045c5034b0be ] arch_kimage_file_post_load_cleanup() and load_other_segments(), both inside the CONFIG_KEXEC_FILE block, take a struct kimage pointer before the forward declaration appears. Move the forward declaration above so it precedes its first use instead of relying on a transitive include. Fixes: d162feec6b6e ("LoongArch: Add preparatory infrastructure for kexec_file") Signed-off-by: 谢致邦 (XIE Zhibang) Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit fe0669928f27bb45e31dc298edf17245e4c42bc6 Author: Inochi Amaoto Date: Tue Jun 23 15:46:35 2026 +0800 net: stmmac: dwmac-spacemit: Fix wrong irq definition [ Upstream commit bf5cd5d4ca423d348e01b3bbcdccd0e02b1b408b ] The current irq definition of the wake irq and the lpi irq is wrong, replace them with the right number and name. Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260623074637.503864-3-inochiama@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a77abd7a34906a86523d7bea06dfe3eab638a379 Author: Inochi Amaoto Date: Tue Jun 23 15:46:34 2026 +0800 net: stmmac: dwmac-spacemit: Fix wrong phy interface definition [ Upstream commit d1e3a4c3b24d4430d9987a3f349c6c2a959a389a ] The current MII interface register definition from the vendor is wrong, use the right number for the macro. Also, correct the interface mask in spacemit_set_phy_intf_sel() so it can update the register with the right number Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260623074637.503864-2-inochiama@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c3e27e4ee524e0d683e90b992b4981fcdc9a747e Author: Shitalkumar Gandhi Date: Tue Jun 23 12:11:42 2026 +0530 net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove [ Upstream commit a9e29dcd8a84081177f693439d663ca9e216c9fa ] mac->phy_node is acquired via of_parse_phandle() in spl2sw_probe() and stored in the mac private data, transferring ownership of the device_node reference to mac. On driver removal, spl2sw_phy_remove() disconnects the PHY but never drops that reference, so each probe-then-remove cycle leaks one of_node refcount per port permanently. Drop the reference after phy_disconnect(). While at it, remove the redundant inner "if (ndev)" check; comm->ndev[i] was just verified non-NULL on the line above. Compile-tested only; no SP7021 hardware available. Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021") Signed-off-by: Shitalkumar Gandhi Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/f3bdd4c91f3e2269b4e256075f9dc70808b1b8e9.1782195965.git.shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bc49e8746584564dba47d963d1916cc876fc6f6b Author: Ruoyu Wang Date: Tue Jun 23 10:57:59 2026 +0800 net: sungem: fix probe error cleanup [ Upstream commit 36dea2f639249460d13f6ca66b2a9064187cd34d ] gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ruoyu Wang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260623025759.3468566-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb42560afec5058b459853f554d019a9e144ddc9 Author: Greg Thelen Date: Mon Jun 22 09:16:59 2026 -0700 tools: ynl: build archives with $(AR) [ Upstream commit 8c37e76f960b7a201556e954b987b431820995ee ] Use $(AR) to allow build system to override the archiver tool (e.g., when cross-compiling for a different architecture) by setting the AR environment variable. GNU Make defaults AR to ar, so this change will not break existing build environments that do not explicitly set AR. Fixes: 07c3cc51a085 ("tools: net: package libynl for use in selftests") Fixes: 86878f14d71a ("tools: ynl: user space helpers") Signed-off-by: Greg Thelen Link: https://patch.msgid.link/20260622161659.145047-1-gthelen@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2087447f562692ff0cd08a0554d8d4ad083aa5c Author: Xiang Mei Date: Wed Jun 17 20:26:22 2026 -0700 geneve: validate inner network offset in geneve_gro_complete() [ Upstream commit cbb0d30a1ad6fc9439b1dc9b4f5a7a9140d3b11f ] Even with both paths gated on gs->gro_hint, geneve_gro_complete() re-derives the inner dispatch type and length from the packet and the current gs->gro_hint, independently of geneve_gro_receive(). The two can disagree if gs->gro_hint flips under a concurrent geneve_quiesce()/ geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if the re-read option bytes differ from the ones receive parsed. geneve_gro_receive() already records the inner network header position in NAPI_GRO_CB()->inner_network_offset. Have geneve_gro_complete() compute the offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case where eth_gro_complete() steps over the inner MAC header, and bail out if it lands past inner_network_offset. Use a lower bound rather than exact equality: between gh_len and the inner L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag (vlan_gro_receive() advances the recorded offset past it), which only moves inner_network_offset further out. A valid frame therefore always satisfies inner_nh <= inner_network_offset, while a gh_len inflated by a hint gro_receive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected. Fixes: fd0dd796576e ("geneve: use GRO hint option in the RX path") Suggested-by: Paolo Abeni Co-developed-by: Weiming Shi Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260618032622.484720-2-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 49c2e7c0a69999a75ef5eaebe1559a20d0b3c15a Author: Xiang Mei Date: Wed Jun 17 20:26:21 2026 -0700 geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint [ Upstream commit 2651c174445884ac9e85622aeade9c1f7b98d8e5 ] geneve_gro_receive() reads the GRO hint through geneve_sk_gro_hint_off(), which honours it only when the socket enabled IFLA_GENEVE_GRO_HINT (gs->gro_hint). geneve_gro_complete() instead calls the low-level geneve_opt_gro_hint_off() and acts on the hint unconditionally. On a tunnel without the hint, receive aggregates the frames as plain ETH_P_TEB while complete still honours an attacker-supplied hint option: it inflates gh_len by gro_hint->nested_hdr_len (u8) and redirects the dispatch type, so the inner gro_complete handler runs at nhoff + gh_len, an offset receive never pulled nor validated, reading out of bounds of the skb head: BUG: KASAN: slab-out-of-bounds in ipv6_gro_complete (net/ipv6/ip6_offload.c:196) Read of size 1 at addr ffff88800fe91980 by task exploit/153 ipv6_gro_complete (net/ipv6/ip6_offload.c:196) geneve_gro_complete (drivers/net/geneve.c:965) udp_gro_complete (net/ipv4/udp_offload.c:940) inet_gro_complete (net/ipv4/af_inet.c:1621) __gro_flush (net/core/gro.c:306) Gate the complete path on gs->gro_hint too via geneve_sk_gro_hint_off(), so both paths agree. Tunnels that enable the hint are unaffected. Fixes: fd0dd796576e ("geneve: use GRO hint option in the RX path") Reported-by: Weiming Shi Reported-by: Kyle Zeng Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260618032622.484720-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5bdb33ff6e58bdc43632e98b30723eb65352d671 Author: Yun Zhou Date: Mon Jun 22 15:43:50 2026 +0800 net: mvneta: re-enable percpu interrupt on resume [ Upstream commit fd398d6480987e4c84fff0aaab6b9d6642a93343 ] On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state. Fixes: 12bb03b436da ("net: mvneta: Handle per-cpu interrupts") Signed-off-by: Yun Zhou Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260622074350.1666290-1-yun.zhou@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fd234bc1264da86aebd57f02955d5ac8e26ee73 Author: Ratheesh Kannoth Date: Mon Jun 22 09:12:29 2026 +0530 octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks [ Upstream commit 469f4462ec83119e8bc0e4699ad01d80a9a4c61a ] CGX per-lmac debugfs seq readers obtained struct rvu via pci_get_drvdata(pci_get_device(..., PCI_DEVID_OCTEONTX2_RVU_AF, ...)), which leaks a PCI device reference on every read. Store rvu and the CGX handle in debugfs inode private data when creating stats, mac_filter, and fwdata files (one context per CGX), and use debugfs aux numbers for fwdata so lmac_id matches the other CGX debugfs entries. Fixes: f967488d095e ("octeontx2-af: Add per CGX port level NIX Rx/Tx counters") Fixes: dbc52debf95f ("octeontx2-af: Debugfs support for DMAC filters") Fixes: 49f02e6877d1 ("Octeontx2-af: Debugfs support for firmware data") Cc: Linu Cherian Reported-by: Yuho Choi Reviewed-by: Simon Horman Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260622034229.2254145-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1f6381acf9d55fab208e8b4c252a5a671820bd9 Author: Subbaraya Sundeep Date: Mon Jun 22 04:30:53 2026 +0530 octeontx2-af: Validate NIX maximum LFs correctly [ Upstream commit 1576d12a39860418d6a68b402fda71a48f04a57c ] NIX maximum number of LFs can be set via devlink command but that can be done before assigning any LFs to a PF/VF. The condition used to check whether any LFs are assigned is incorrect. This patch fixes that condition. Fixes: dd7842878633 ("octeontx2-af: Add new devlink param to configure maximum usable NIX block LFs") Signed-off-by: Subbaraya Sundeep Link: https://patch.msgid.link/1782082853-6941-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba933c5f3568518f36695bb1970fceb20d2cd7d4 Author: Jan Klos Date: Sat Jun 20 03:19:53 2026 +0200 net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit [ Upstream commit 510a283f4d12367a3f811f382a2c89202954bbd1 ] On RTL8127A connected to a link partner that advertises 10000baseT speed cannot be changed to anything other than 10000baseT as 10GbE is always advertised regardless of any setting. Fix this by clearing MDIO_AN_10GBT_CTRL_ADV10G bit in rtl822x_config_aneg()'s call to phy_modify_mmd_changed(). Fixes: 83d962316128 ("net: phy: realtek: add RTL8127-internal PHY") Reviewed-by: Maxime Chevallier Signed-off-by: Jan Klos Link: https://patch.msgid.link/20260620011956.37181-1-honza.klos@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d47925c2c64b3eddc81067552caf486c743ab7e Author: Erni Sri Satya Vennela Date: Thu Jun 18 22:53:38 2026 -0700 net: mana: Fall back to standard MTU when PF reports adapter_mtu of 0 [ Upstream commit 6bd81a5b4e0dbec2feb94a456bca9d9f00bc14b3 ] Commit d7709812e13d ("net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIG") rejected any adapter_mtu value smaller than ETH_MIN_MTU + ETH_HLEN, including 0, returning -EPROTO and failing mana_probe(). Some older PF firmware versions still in the field report adapter_mtu as 0 in the MANA_QUERY_DEV_CONFIG response. With the hardening check in place, the MANA VF driver now fails to load on those hosts, breaking networking entirely for guests. MANA hardware always supports the standard Ethernet MTU. Treat a reported adapter_mtu of 0 as "the PF did not advertise a value" and fall back to ETH_FRAME_LEN, the same value used for the pre-V2 message version path. Only jumbo frames remain unavailable until the PF reports a valid MTU. Other small-but-nonzero bogus values are still rejected, preserving the original protection against the unsigned-subtraction wrap that would otherwise let ndev->max_mtu underflow to a huge value. Fixes: d7709812e13d ("net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIG") Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260619055348.467224-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cf52622fbc274eb4ca9a2066b258da2ae3dc7406 Author: Daniel Golle Date: Fri Jun 19 04:40:14 2026 +0100 net: dsa: mxl862xx: fix use-after-free of DSA ports in crc_err_work [ Upstream commit bcb3b8314611ed9cb4ff4bff484ef9b154fd1b83 ] Upon an MDIO CRC error mxl862xx_crc_err_work_fn() walks the DSA ports and closes the CPU port conduits: dsa_switch_for_each_cpu_port(dp, priv->ds) dev_close(dp->conduit); mxl862xx_remove() unregisters the switch before cancelling this work: set_bit(MXL862XX_FLAG_WORK_STOPPED, &priv->flags); cancel_delayed_work_sync(&priv->stats_work); dsa_unregister_switch(ds); mxl862xx_host_shutdown(priv); dsa_unregister_switch() frees the dsa_port objects. If a CRC error schedules the work during teardown it can run after the ports have been freed and dereference freed memory. Guard the port walk with MXL862XX_FLAG_WORK_STOPPED, which is already set before dsa_unregister_switch(). DSA tears the ports down under rtnl_lock(), so checking the flag under rtnl_lock() means the work either runs before teardown and sees valid ports, or runs afterwards, observes the flag and skips the walk. This mirrors the host_flood_work handler, which skips torn-down ports under rtnl_lock(). Link: https://sashiko.dev/#/patchset/cover.1780968180.git.daniel%40makrotopia.org?part=2 Fixes: a319d0c8c8ce ("net: dsa: mxl862xx: add CRC for MDIO communication") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/5e55169926c02f2b914e5ada529d7453b943cda4.1781702256.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 245c6c8a2958e9ece688ade7df9c8d8f2809984e Author: Daniel Golle Date: Fri Jun 19 04:39:25 2026 +0100 net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap [ Upstream commit 6b3f7af57881f6d6250c6dcc4d910fe8e855a607 ] The MXL862XX_API_* macros pass the address of a stack-allocated, __packed firmware-ABI struct to mxl862xx_api_wrap() as a void *. The struct has an alignment of 1, so the compiler is free to place it at an odd address. mxl862xx_api_wrap() reinterprets that buffer as a __le16 * and accesses it with data[i], for which the compiler assumes the natural 2-byte alignment of __le16 and emits aligned 16-bit loads/stores (e.g. lhu/sh on MIPS). When the buffer lands on an odd address these fault on architectures that do not support unaligned access, such as MIPS32. -Waddress-of-packed-member does not catch this: the packed origin is laundered through the void * parameter, so the cast inside api_wrap looks alignment-safe to the compiler and no warning is emitted. Use get_unaligned_le16()/put_unaligned_le16() for the three 16-bit word accesses. The byte accesses (*(u8 *)&data[i], crc16()) are already safe and are left unchanged. Link: https://sashiko.dev/#/patchset/cover.1781319534.git.daniel%40makrotopia.org?part=4 Fixes: 23794bec1cb6 ("net: dsa: add basic initial driver for MxL862xx switches") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/599327521db465a534d277de53ab9b6cac01928b.1781702256.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c21f7ee511ae8851dd053269220db985b1ded0c8 Author: David Yang Date: Thu Jun 18 22:01:55 2026 +0800 net: dsa: realtek: fix memory leak in rtl8366rb_setup_led() [ Upstream commit 056a5087d87ead77dedbe9cf5bde53b7cd4b4651 ] led_classdev_register_ext() only reads init_data.devicename - it never stores the pointer. However, the caller allocated devicename with kasprintf() but never freed it, leaking the string memory. Fix it with a stack buffer to avoid dynamic buffers completely. Fixes: 32d617005475 ("net: dsa: realtek: add LED drivers for rtl8366rb") Signed-off-by: David Yang Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260618140200.1888707-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a427cfa417962a1c6cbdde335091a51f28a7cf5c Author: Haoxiang Li Date: Tue Jun 23 18:08:48 2026 +0800 rtc: cmos: unregister HPET IRQ handler on probe failure [ Upstream commit a5bb580df018b5d1c5668f05f7979044fb19e23a ] cmos_do_probe() registers cmos_interrupt() as the HPET RTC IRQ handler before requesting the RTC IRQ and registering the RTC device. If either request_irq() or devm_rtc_register_device() fails afterwards, the error path leaves the HPET RTC IRQ handler installed. This leaves a stale handler behind and make a later hpet_register_irq_handler() fail with -EBUSY. Track whether the HPET handler was registered successfully and undo the registration on the probe error path. Also mask the HPET RTC IRQ bits to match the normal shutdown cleanup. Fixes: 9d8af78b0797 ("rtc: add HPET RTC emulation to RTC_DRV_CMOS") Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260623100848.2127281-1-haoxiang_li2024@163.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 5904fd94f919083151afffb830e9407372a60342 Author: Fredrik M Olsson Date: Wed May 20 16:48:54 2026 +0200 rtc: ds1307: Fix off-by-one issue with wday for rx8130 [ Upstream commit 6882aab3c66112b33b251be95c09c8ead3e8d580 ] The RTC represent each weekday with a individual bit set in the WDAY register, where the 0th bit represent the first day of the week and the 6th bit represents the last day of the week. For each passed day the chip performs a rotary-left-shift by one to advance the weekday by one. The tm_wday field represent weekdays by a value in the range of 0-6. The fls() function return the bit index of the last bit set. To handle when there are no bits set it will return 0, and if the 0th bit is set it will return 1, and if the 1st bit is set it will return 2, and so on. In order to make the result of the fls() function fall into the expected range of 0-6 (instead of 1-7) this patch subtracts one from the result (which matches how the value is written in ds1307_set_time()). Fixes: 204756f016726 ("rtc: ds1307: Fix wday settings for rx8130") Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Fredrik M Olsson Link: https://patch.msgid.link/20260520-ds1307-rx8901-add-v2-2-e069ea32e1db@axis.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cddbfbc71085005c75d975d8729f56ff0d55e986 Author: Huiwen He Date: Wed Jun 24 10:15:43 2026 +0800 smb/client: preserve errors from smb2_set_sparse() [ Upstream commit 2a4b3d2db5c6fcdba889baf7b2ae5661b0beac89 ] smb2_set_sparse() converts every FSCTL_SET_SPARSE failure to false and marks sparse support as broken for the share. Callers therefore report EOPNOTSUPP even for errors such as ENOSPC or EACCES, and later sparse operations remain disabled until the share is unmounted. Return the SMB2 ioctl error directly. Set broken_sparse_sup only for EOPNOTSUPP, which indicates that the server does not support the request. Update smb3_punch_hole() to propagate the error returned by smb2_set_sparse(). Fixes: 3d1a3745d8ca ("Add sparse file support to SMB2/SMB3 mounts") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8bbe4dd7964552f74c271c3a8d95a4331a8ab5f9 Author: Li RongQing Date: Tue Jun 16 15:26:17 2026 +0800 ACPI: processor_idle: Mark LPI enter functions as __cpuidle [ Upstream commit 956ca5d72c76504824c8eb601879da9476973e15 ] When function tracing or Kprobes is enabled, entering an ACPI Low Power Idle (LPI) state triggers the following RCU splat: RCU not on for: acpi_idle_lpi_enter+0x4/0xd8 WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228 The acpi_idle_lpi_enter() function is invoked within the cpuidle path after RCU has already been disabled for the current local CPU. Consequently, ftrace's function_trace_call() expects RCU to be actively watching before recording trace data, emitting a warning if it is not. Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with __cpuidle. This moves these functions into the '.cpuidle.text' section, implicitly disabling ftrace instrumentation (notrace) along this sensitive path and preventing trace-induced RCU warnings during idle entry. Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states") Signed-off-by: Li RongQing Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/20260616072617.2272-1-lirongqing@baidu.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 42d4fc933280ccdb48ddbaa768a51db3fbed5ce8 Author: Rafael J. Wysocki Date: Mon Jun 22 20:23:09 2026 +0200 ACPICA: Unbreak tools build after switching over to strscpy_pad() [ Upstream commit 292db66afd20dd0b7a3c9a3dad9b864a64c8bddf ] Commit 97f7d3f9c9ac ("ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()") switched over the ACPICA code in the kernel to using strscpy_pad() instead of a combination of strncpy() and manual NUL-termination of the destination string, but it overlooked the fact that tools also use the code in question and strscpy_pad() is not defined in those builds. Address that by using the original ACPICA code in non-kernel builds. Fixes: 97f7d3f9c9ac ("ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()") Reported-by: Jiri Slaby Closes: https://lore.kernel.org/all/79e9e913-0fb1-4110-804b-c3b5d0edafe4@kernel Signed-off-by: Rafael J. Wysocki Reviewed-by: Kees Cook [ rjw: Fixed up the number of added code lines ] Link: https://patch.msgid.link/12923581.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 156af6606f366ab7fe748573605ecec819a6722f Author: Rafael J. Wysocki Date: Fri Jun 19 17:01:27 2026 +0200 thermal: testing: zone: Flush work items during cleanup [ Upstream commit fb1a5dfe86d3af1e1c3ce168cf0d8d43897e0f77 ] To prevent freed module code from being executed during the thermal testing module unload, make it add a dedicated workqueue for thermal testing work items and flush it in thermal_testing_exit(). Fixes: f6a034f2df42 ("thermal: Introduce a debugfs-based testing facility") Link: https://sashiko.dev/#/patchset/20260605185212.2491144-1-sam.moelius%40trailofbits.com Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1959388.tdWV9SEqCh@rafael.j.wysocki [ rjw: Make variable d_command static ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fda07c8e4b54b9105f1ca73f0adea7b244d405f4 Author: Claudio Imbrenda Date: Tue Jun 23 17:33:22 2026 +0200 s390/mm: Fix handling of _PAGE_UNUSED pte bit [ Upstream commit d4bb00704a66024502261fa7a523c07420249fea ] The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes. Fixes: c98175b7917f ("KVM: s390: Add gmap_helper_set_unused()") Acked-by: Heiko Carstens Signed-off-by: Claudio Imbrenda Message-ID: <20260623153331.233784-2-imbrenda@linux.ibm.com> Signed-off-by: Sasha Levin commit ca2dbee8fea61341fd04b4fc79ac128a2961ccd6 Author: Jakub Kicinski Date: Mon Jun 22 08:47:53 2026 -0700 eth: fbnic: fix ordering of heartbeat vs ownership [ Upstream commit d87363b0edfc7504ff2b144fe4cdd8154f90f42e ] When requesting ownership of the NIC (MAC/PHY control), we set up the heartbeat to look stale: /* Initialize heartbeat, set last response to 1 second in the past * so that we will trigger a timeout if the firmware doesn't respond */ fbd->last_heartbeat_response = req_time - HZ; fbd->last_heartbeat_request = req_time; The response handler then sets: fbd->last_heartbeat_response = jiffies; for which we wait via: fbnic_fw_init_heartbeat() -> fbnic_fw_heartbeat_current() The scheme is a bit odd, but it should work in principle. Fix the ordering of operations. We have to set up the stale heartbeat before we send the message. Otherwise if the response is very fast we will override it. This triggers on QEMU if we run on the core that handles the IRQ, and results in ndo_open failing with ETIMEDOUT. The change in ordering doesn't impact releasing the ownership. Both ndo_stop and heartbeat check are under rtnl_lock. Fixes: 20d2e88cc746 ("eth: fbnic: Add initial messaging to notify FW of our presence") Reviewed-by: Alexander Duyck Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260622154753.827506-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7a368c754a96690d9a8fb456aebecacbb24320fb Author: Fernando Fernandez Mancera Date: Mon Jun 22 15:08:57 2026 +0200 ipv6: fix missing notification for ignore_routes_with_linkdown [ Upstream commit 17dc3b245de45b1f2012e3a48ec51889f544e67b ] When changing the ignore_routes_with_linkdown sysctl for a specific interface, the RTM_NEWNETCONF netlink notification was not being emitted to userspace. Fix this by emitting the notification when needed. In addition, fix bogus return value for successful "all" and specific interface write operation leading to a wrong reset of the position pointer. Fixes: 35103d11173b ("net: ipv6 sysctl option to ignore routes when nexthop link is down") Reviewed-by: Nicolas Dichtel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260622130857.5115-7-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b91ac71fc2a2a3ab749d48b0c51a6b94d4d48b19 Author: Fernando Fernandez Mancera Date: Mon Jun 22 15:08:56 2026 +0200 ipv6: fix state corruption during proxy_ndp sysctl restart [ Upstream commit 6a1b50e585f033f3e201f42a18b37f070095fb80 ] When handling proxy_ndp, if rtnl_net_trylock() fails, the operation is retried but as the value was already modified by the initial proc_dointvec() call, the restarted syscall will read the newly modified value as the 'old' state. Fix this by taking the RTNL lock before parsing the input value if the operation is a write. Fixes: c92d5491a6d9 ("netconf: add support for IPv6 proxy_ndp") Reviewed-by: Nicolas Dichtel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260622130857.5115-6-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 764ac02cbd3b4464df7fc4237d7e9753f0bf6c08 Author: Fernando Fernandez Mancera Date: Mon Jun 22 15:08:55 2026 +0200 ipv6: fix error handling in disable_policy sysctl [ Upstream commit 3e0e51c0ee1d08cc9d48dc17f3248d5b31cf8066 ] When writing to the disable_policy sysctl, if proc_dointvec() fails to parse the input, it returns a negative error code. The current implementation is resetting the position argument even if an error occurred during proc_dointvec() and not only during sysctl restart. Fix this by checking the return value of proc_dointvec() and returning early on failure. Fixes: df789fe75206 ("ipv6: Provide ipv6 version of "disable_policy" sysctl") Reviewed-by: Nicolas Dichtel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260622130857.5115-5-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 420e895fb41de2188cb288c564b4589793579eca Author: Fernando Fernandez Mancera Date: Mon Jun 22 15:08:54 2026 +0200 ipv6: fix error handling in forwarding sysctl [ Upstream commit 058b9b19f9639fe1e1225a17c540f61b65bee6ad ] When writing to the forwarding sysctl, if proc_dointvec() fails to parse the input, it returns a negative error code. The current implementation is overwriting that error for write operations. This results in a silent failure, it returns a successful write although the configuration was not modified at all. When modifying the "all" variant it can also modify the configuration of existing interfaces to the wrong value. Fix this by checking the return value of proc_dointvec() and returning early on failure. In addition, adjust return code of addrconf_fixup_forwarding() for successful operation. Fixes: b325fddb7f86 ("ipv6: Fix sysctl unregistration deadlock") Reviewed-by: Nicolas Dichtel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260622130857.5115-4-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a39ff02a241cf5c65465cc11ae158f3cece7e186 Author: Fernando Fernandez Mancera Date: Mon Jun 22 15:08:53 2026 +0200 ipv6: fix error handling in ignore_routes_with_linkdown sysctl [ Upstream commit cf4f2b14401f29ccac56393ca9e4b42a2505f540 ] When writing to the ignore_routes_with_linkdown sysctl, if proc_dointvec() fails to parse the input, it returns a negative error code. The current implementation is overwriting that error for write operations. This results in a silent failure, it returns a successful write although the configuration was not modified at all. When modifying the "all" variant it can also modify the configuration of existing interfaces to the wrong value. Fix this by checking the return value of proc_dointvec() and returning early on failure. Fixes: 35103d11173b ("net: ipv6 sysctl option to ignore routes when nexthop link is down") Reviewed-by: Nicolas Dichtel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260622130857.5115-3-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e28bada56f4ffbdeab6ca6be9724a1e2cf793b20 Author: Fernando Fernandez Mancera Date: Mon Jun 22 15:08:52 2026 +0200 ipv6: fix error handling in disable_ipv6 sysctl [ Upstream commit c779441e5070e2268bdfe77f6e2e0de926c431e3 ] When writing to the disable_ipv6 sysctl, if proc_dointvec() fails to parse the input, it returns a negative error code. The current implementation is overwriting that error for write operations. This results in a silent failure, it returns a successful write although the configuration was not modified at all. When modifying the "all" variant it can also modify the configuration of existing interfaces to the wrong value. Fix this by checking the return value of proc_dointvec() and returning early on failure. Fixes: 56d417b12e57 ("IPv6: Add 'autoconf' and 'disable_ipv6' module parameters") Reviewed-by: Nicolas Dichtel Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260622130857.5115-2-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94f55994e19e8f0676990b9d5015b58ab6a97e00 Author: Xin Long Date: Sat Jun 20 11:48:54 2026 -0400 sctp: fix err_chunk memory leaks in INIT handling [ Upstream commit 9f58a0a4d6c2ed5d341bba64f058f15d1b0c36f2 ] When sctp_verify_init() encounters unrecognized parameters, it allocates an err_chunk to report them. However, this chunk is leaked in several code paths: 1. In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after sctp_verify_init() has populated err_chunk, the function returns immediately without freeing it. 2. In sctp_sf_do_unexpected_init(), the same leak occurs on the security_sctp_assoc_request() failure path. 3. In sctp_sf_do_unexpected_init(), on the success path after copying unrecognized parameters to the INIT-ACK, the function returns without freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees it. Fix all three leaks by adding sctp_chunk_free(err_chunk) calls before returning in the error paths and on the success path in sctp_sf_do_unexpected_init(). Fixes: c081d53f97a1 ("security: pass asoc to sctp_assoc_request and sctp_sk_clone") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Signed-off-by: Xin Long Reviewed-by: Simon Horman Link: https://patch.msgid.link/0656704f1b0158287c98aec09ba36c83e4a537ab.1781970534.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e28aedab9488343924d227b5a896faed67ce84d5 Author: Jamal Hadi Salim Date: Sat Jun 20 09:07:49 2026 -0400 net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle [ Upstream commit a8a02897f2b479127db261de05cbf0c28b98d159 ] tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us. Fixes: 3f14b377d01d ("net/sched: act_ct: fix skb leak and crash on ooo frags") Reported-by: Zero Day Initiative Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260620130749.226642-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19eec11f3ab5dd29ba58f5f209c24e946c95ef12 Author: Jakub Sitnicki Date: Fri Jun 19 19:09:28 2026 +0200 net: lwtunnel: Drop skb metadata before LWT encapsulation [ Upstream commit c00320b0e355c4bf0ae4743a53b4180fea237546 ] skb metadata is meant for passing information between XDP and TC. It lives in the skb headroom, immediately before skb->data. LWT programs cannot access the __sk_buff->data_meta pseudo-pointer to metadata. However, LWT encapsulation prepends outer headers, moving skb->data back over the headroom where the metadata sits. On an RX-originated (forwarded) packet that still carries XDP metadata this goes wrong in two different ways, depending on the encap type: 1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull() and silently overwrite the metadata that sits in the headroom. 2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move(). That helper expects metadata immediately before skb->data. But since the IP output path runs LWT xmit before neighbour output has built the outgoing L2 header, for forwarded packets skb->data points at the L3 header while skb_mac_header() still points at the old L2 header. skb_data_move() sees metadata ending at skb_mac_header(), not before skb->data, warns and clears metadata: WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90 CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1 RIP: 0010:skb_data_move+0x47/0x90 Call Trace: bpf_skb_change_head+0xe6/0x1a0 bpf_prog_...+0x213/0x2e3 run_lwt_bpf.isra.0+0x1d3/0x360 bpf_xmit+0x46/0xe0 lwtunnel_xmit+0xa1/0xf0 ip_finish_output2+0x1e7/0x5e0 ip_output+0x63/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x2b/0x190 net_rx_action+0x40b/0x7f0 handle_softirqs+0xd2/0x270 do_softirq+0x3f/0x60 That is what happens, as for how to fix it - a received packet that carries metadata can reach an encap through any of the three LWT redirect modes: LWTUNNEL_STATE_INPUT_REDIRECT ip6_rcv_finish dst_input lwtunnel_input LWTUNNEL_STATE_OUTPUT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output lwtunnel_output LWTUNNEL_STATE_XMIT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output ip6_output ip6_finish_output ip6_finish_output2 lwtunnel_xmit Every encap funnels through the three LWT dispatch helpers, so drop the metadata there, right before handing the skb to the encap op. This single chokepoint covers all encap types and all three redirect modes: - lwtunnel_input(): seg6, rpl, ila, seg6_local - lwtunnel_output(): ioam6 - lwtunnel_xmit(): mpls, LWT BPF xmit Alternatively, we could clear the metadata right after TC ingress hook. That would require a compromise, however. Metadata would become inaccessible from TC egress (in setups where it actually reaches the hook it tact, that is without any L2 tunnels on path). Fixes: 8989d328dfe7 ("net: Helper to move packet data and metadata after skb_push/pull") Signed-off-by: Jakub Sitnicki Link: https://patch.msgid.link/20260619-bpf-lwt-drop-skb-metadata-v3-1-71d6a33ab76b@cloudflare.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc27e4514e6e67324176215689b8f9e8994ea756 Author: Nicolai Buchwitz Date: Mon Jun 22 12:29:11 2026 +0200 net: usb: lan78xx: restore VLAN and hash filters after link up [ Upstream commit 5c12248673c76f10ab900f70724c5da288c7efa5 ] Configured VLANs intermittently stop receiving traffic after a link down/up cycle, e.g. when the network cable is unplugged and plugged back in. VLAN filtering stays enabled but all VLAN-tagged frames are dropped until a VLAN is added or removed again. The LAN7801 datasheet (DS00002123E) states: "A portion of the MAC operates on clocks generated by the Ethernet PHY. During a PHY reset event, this portion of the MAC is designed to not be taken out of reset until the PHY clocks are operational" (section 8.10, MAC Reset Watchdog Timer) "After a reset event, the RFE will automatically initialize the contents of the VHF to 0h." (section 7.1.4, VHF Organization) Thus a link down/up cycle stops and restarts the PHY clock, resets the PHY-clocked portion of the MAC, and the RFE clears its VLAN/DA hash filter (VHF) memory. The VHF holds both the VLAN filter table and the multicast hash table, but the driver never reprograms either from its shadow copy once the link is back, so both stay empty. Reprogram the VLAN filter and multicast hash tables on link up. Reported-by: Sven Schuchmann Closes: https://lore.kernel.org/netdev/BEZP281MB224501E38B30BFDC4BD3D364D9E32@BEZP281MB2245.DEUP281.PROD.OUTLOOK.COM/T/#u Tested-by: Sven Schuchmann Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260622102911.484045-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4bd2e5dbe62334aae1182d0f0d260f334a49d739 Author: Eric Dumazet Date: Mon Jun 22 11:18:25 2026 +0000 veth: fix NAPI leak in XDP enable error path [ Upstream commit 6739027cb72da26890edd424c77080d187b2a92e ] During XDP enablement in veth, if xdp_rxq_info_reg() or xdp_rxq_info_reg_mem_model() fails, the driver rolls back the changes. However, the rollback loop: for (i--; i >= start; i--) { decrements the loop index 'i' before the first iteration. This correctly skips unregistering the rxq for the failed index 'i' (as registration failed or was already cleaned up), but it also erroneously skips calling netif_napi_deli() for rq[i].xdp_napi. Since netif_napi_add() was already called for index 'i', this leaves a dangling napi_struct in the device's napi_list. When the veth device is later destroyed, the freed queue memory (which contains the leaked NAPI structure) can be reused. The subsequent device teardown iterates the NAPI list and corrupts the reallocated memory, leading to UAF. Fix this by explicitly deleting the NAPI association for the failed index 'i' before rolling back the successfully configured queues. Fixes: b02e5a0ebb17 ("xsk: Propagate napi_id to XDP socket Rx path") Reported-by: Guenter Roeck Signed-off-by: Eric Dumazet Cc: Björn Töpel Cc: Daniel Borkmann Cc: Ilias Apalodimas Cc: Michael S. Tsirkin Cc: Tariq Toukan Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260622111825.88337-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20d4a9dea55b7a939d11470ffd2eeda2d9733d46 Author: Meghana Malladi Date: Thu Jun 18 15:33:48 2026 +0530 net: ti: icssg: Fix XSK zero copy TX during application wakeup [ Upstream commit d95ea4bc09e88fe00f8e1c4e27c021313a4139c7 ] emac_xsk_xmit_zc() handles tx xmit for zero copy and gets called inside napi context. User application wakes up the kernel while initiating the transmit which triggers napi to start processing the tx packets. The num_tx check inside emac_tx_complete_packets() returns early if no packet transfer happen hindering the call to emac_xsk_xmit_zc(). Remove this check to let application wakeup initiate zero copy xmit traffic. Add __netif_tx_lock() to ensure that the TX queue is protected from concurrent access during the transmission of XDP frames. This fixes netdev watchdog timeout for long runs. Fixes: e2dc7bfd677f ("net: ti: icssg-prueth: Move common functions into a separate file") Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20260618100348.2209907-1-m-malladi@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09efce96c909dff1a9317ec3714b7ddb4751b7af Author: Aleksandrova Alyona Date: Thu Jun 18 14:05:08 2026 +0300 net: dsa: sja1105: round up PTP perout pin duration [ Upstream commit aee5836273b07b439fb245fb43930664d8b78518 ] pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time(). Fixes: 747e5eb31d59 ("net: dsa: sja1105: configure the PTP_CLK pin as EXT_TS or PER_OUT") Signed-off-by: Aleksandrova Alyona Link: https://patch.msgid.link/20260618110508.53094-1-aga@itb.spb.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3d0c8b437efe4af31ad5a02f648cf1b3a533531 Author: Eric Dumazet Date: Mon Jun 22 11:01:08 2026 +0000 net: do not acquire dev->tx_global_lock in netdev_watchdog_up() [ Upstream commit d09a78a2a469e4fab75108325efb813c49520809 ] Marek Szyprowski reported a deadlock during system resume when virtio_net driver is used. The deadlock occurs because netif_device_attach() is called while holding dev->tx_global_lock (via netif_tx_lock_bh() in virtnet_restore_up()). netif_device_attach() calls __netdev_watchdog_up(), which now also tries to acquire dev->tx_global_lock to synchronize with dev_watchdog(). This recursive lock acquisition results in a deadlock. Fix this by removing the tx_global_lock acquisition from netdev_watchdog_up(). The critical state (watchdog_timer and watchdog_ref_held) is already protected by dev->watchdog_lock, which was introduced in the blamed commit. Fixes: 8eed5519e496 ("net: watchdog: fix refcount tracking races") Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/netdev/a443376e-5187-4268-93b3-58047ef113a8@samsung.com/ Signed-off-by: Eric Dumazet Tested-by: Marek Szyprowski Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260622110108.69541-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 89c103d702b25ceb2d097faf854deb47b53b17ff Author: Xiang Mei Date: Sat Jun 20 13:15:31 2026 -0700 net, bpf: check master for NULL in xdp_master_redirect() [ Upstream commit e82d8cc4321c373dc46e741cd2dfdaa7921fddb7 ] xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 ("net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up. Fixes: 879af96ffd72 ("net, core: Add support for XDP redirection to slave device") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260620201531.180123-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 752b781b0c0ae5a725d108f3cefa828deeff1415 Author: Doehyun Baek Date: Mon Jun 22 18:18:21 2026 +0000 Docs/driver-api/uio-howto: document mmap_prepare callback [ Upstream commit de5c46373eb8148aa92c024cf30d26a6d495e278 ] The UIO howto still documents an mmap callback in struct uio_info. That field was replaced by mmap_prepare, which takes a struct vm_area_desc. A UIO driver following the current howto no longer builds because struct uio_info has no mmap member. Update the documented callback signature and matching text to match the current API. Fixes: 933f05f58ac6 ("uio: replace deprecated mmap hook with mmap_prepare in uio_info") Signed-off-by: Doehyun Baek Reviewed-by: Lorenzo Stoakes Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260622181821.1195257-1-doehyunbaek@gmail.com> Signed-off-by: Sasha Levin commit c19faa40b37d7fb6b52ce055ca5714108fdb897e Author: Krzysztof Wilczyński Date: Fri May 8 04:35:33 2026 +0000 alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs [ Upstream commit 802a3b3f470b9bc1148f26e01fc9cbfeb4dfcb57 ] Currently, __pci_mmap_fits() computes the BAR size using "pci_resource_len() - 1", which wraps to a large value when the BAR length is zero, causing the bounds check to incorrectly succeed. Add an early return for empty resources. Fixes: 10a0ef39fbd1 ("PCI/alpha: pci sysfs resources") Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Magnus Lindholm Tested-by: Shivaprasad G Bhat Reviewed-by: Ilpo Järvinen Acked-by: Magnus Lindholm Link: https://patch.msgid.link/20260508043543.217179-15-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 257b55dc3d18d7ef01f62a8ff7317871f7597e28 Author: Krzysztof Wilczyński Date: Fri May 8 04:35:30 2026 +0000 alpha/PCI: Add security_locked_down() check to pci_mmap_resource() [ Upstream commit 78a228f0aa0e9eba31955950c8a40a9945e2c8bb ] Currently, Alpha's pci_mmap_resource() does not check security_locked_down(LOCKDOWN_PCI_ACCESS) before allowing userspace to mmap PCI BARs. The generic version has had this check since commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") to prevent DMA attacks when the kernel is locked down. Add the same check to Alpha's pci_mmap_resource(). Fixes: eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Magnus Lindholm Tested-by: Shivaprasad G Bhat Reviewed-by: Ilpo Järvinen Acked-by: Magnus Lindholm Link: https://patch.msgid.link/20260508043543.217179-12-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit 75d7a27c506e4ffe73d7d753929955a06a3e86cf Author: Koichiro Den Date: Wed May 13 11:49:22 2026 +0900 NTB: epf: Fix doorbell bitmask and IRQ vector handling [ Upstream commit 4fdea8dbb62d746429498e07385a3ba0b0f6d1ab ] The EPF driver currently stores the incoming doorbell as a vector number (irq_no + 1) in db_val and db_clear() clears all bits unconditionally. This breaks db_read()/db_clear() semantics when multiple doorbells are used. Store doorbells as a bitmask (BIT_ULL(vector)) and make db_clear(db_bits) clear only the specified bits. Use atomic64 operations as db_val is updated from interrupt context. Once db_val is stored as a bitmask, the ISR's doorbell vector is used not only for ntb_db_event(), but also as the bit index for BIT_ULL(). The existing ISR derives that vector by subtracting pci_irq_vector(pdev, 0) from the Linux IRQ number passed to the handler, but Linux IRQ numbers are not guaranteed to be contiguous. Pass per-vector context as request_irq() dev_id instead, so the ISR gets the device vector directly. Validate the doorbell vector before updating db_val or calling ntb_db_event(), so an unexpected vector cannot create an invalid shift or be reported to NTB clients. While at it, read and validate mw_count before requesting interrupt vectors. An unsupported memory-window count does not need IRQs, and failing before ntb_epf_init_isr() keeps the probe error path simple. Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge") Suggested-by: Dave Jiang Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Dave Jiang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-12-den@valinux.co.jp Signed-off-by: Sasha Levin commit bfe11cd91ab0218abee5f4e1e41215015105405e Author: Koichiro Den Date: Wed May 13 11:49:21 2026 +0900 NTB: epf: Report 0-based doorbell vector via ntb_db_event() [ Upstream commit 3147f0964cecca15e349cbfbdd6a28eb6d50379d ] ntb_db_event() expects the vector number to be relative to the first doorbell vector starting at 0. Vector 0 is reserved for link events in the EPF driver, so doorbells start at vector 1. However, both supported peers (ntb_hw_epf with pci-epf-ntb, and pci-epf-vntb) have historically skipped vector 1 and started doorbells at vector 2. Pass (irq_no - 2) to ntb_db_event() so doorbells are reported as 0..N-1. If irq_no == 1 is ever observed, warn and ignore it, since the slot is reserved in the legacy layout and reporting it as DB#0 would collide with the real DB#0 slot. Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge") Suggested-by: Dave Jiang Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Dave Jiang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-11-den@valinux.co.jp Signed-off-by: Sasha Levin commit 583a4a19eefc3b5c0fe6af9dc66e4ab6880e0ffe Author: Koichiro Den Date: Wed May 13 11:49:20 2026 +0900 NTB: epf: Make db_valid_mask cover only real doorbell bits [ Upstream commit 6eb7e28f1f24a28234add38755687a7ed8bc2654 ] ndev->db_count includes an unused doorbell slot due to the legacy extra offset in the peer doorbell path. db_valid_mask must cover only the real doorbell bits and exclude the unused slot. Set db_valid_mask to BIT_ULL(db_count - 1) - 1. Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260513024923.451765-10-den@valinux.co.jp Signed-off-by: Sasha Levin commit 9787c2d171110d5a0b35ea812be68aad11e7a396 Author: Koichiro Den Date: Wed May 13 11:49:17 2026 +0900 PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask [ Upstream commit 823468a4ea1613f1c1235bd16af8b9c6eb9c9677 ] In pci-epf-vntb, db_count represents the total number of doorbell slots exposed to the peer, including: - slot #0 reserved for link events, and - slot #1 historically unused (kept for compatibility). Only the remaining slots correspond to actual doorbell bits. The current db_valid_mask() exposes all slots as valid doorbells. Limit db_valid_mask() to the real doorbell bits by returning BIT_ULL(db_count - 2) - 1, and guard against db_count < 2. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-7-den@valinux.co.jp Signed-off-by: Sasha Levin commit 9e105f6a14fbe23755ed04df1122b89800466617 Author: Oder Chiou Date: Tue Jun 23 18:25:14 2026 +0800 ASoC: rt5575: Use __le32 for SPI burst write address [ Upstream commit d0c415f0076b71b956f62ff6f31de885f0fa2489 ] The addr field in the SPI burst write buffer represents on-wire little-endian data. Define it as __le32 so that the assignment of cpu_to_le32() is type correct and avoids sparse endian warnings. Closes: https://lore.kernel.org/oe-kbuild-all/202606230139.rFZUVpCa-lkp@intel.com/ Fixes: 420739112e95 ("ASoC: rt5575: Add the codec driver for the ALC5575") Reported-by: kernel test robot Signed-off-by: Oder Chiou Link: https://patch.msgid.link/20260623102514.2422990-1-oder_chiou@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 33387bf9bb6116a0429f823f8dab3accf8f8e09c Author: HyeongJun An Date: Tue Jun 23 20:05:26 2026 +0900 ASoC: SDCA: Validate written enum value in ge_put_enum_double() [ Upstream commit 1ce42a11bed134903e352010a01fa53073a6b395 ] ge_put_enum_double() passes the user-supplied enumeration index item[0] to snd_soc_enum_item_to_val() without checking it against the number of items in the enum: ret = snd_soc_enum_item_to_val(e, item[0]); snd_soc_enum_item_to_val() indexes the heap-allocated e->values[] array with that index (e->values is set from a devm_kcalloc() of e->items entries), so a control write with an out-of-range item[0] reads past the end of the values buffer. The bounds check in snd_soc_dapm_put_enum_double() only runs afterwards, so it does not prevent the read here. Reject an out-of-range item before using it, matching the other enum put handlers. This issue was pointed out by the Sashiko AI review bot while reviewing a related enum-validation series: https://lore.kernel.org/all/20260609125735.CEB651F00893@smtp.kernel.org/ Fixes: 812ff1baa764 ("ASoC: SDCA: Limit values user can write to Selected Mode") Signed-off-by: HyeongJun An Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260623110526.813217-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0ae6e70edc33e9f5b6f3b4ff14e7893bdac7b851 Author: Rafael J. Wysocki Date: Wed Jun 17 18:16:16 2026 +0200 cpuidle: Allow exit latency to exceed target residency [ Upstream commit 68ff4a3ccda9f98c74f23c70c8c7c581f9eee931 ] Commit 76934e495cdc ("cpuidle: Add sanity check for exit latency and target residency") had added a check to prevent the exit latency of an idle state from exceeding its target residency that later was limited to printing a warning message in that case in commit 4bf944f3fcb6 ("cpuidle: Warn instead of bailing out if target residency check fails"). However, a thorough code inspection with that in mind leads to the conclusion that actually there are no assumptions in cpuidle regarding the relationship between the exit latency and target residency of a given idle state. It is generally assumed that the idle states table provided by a cpuidle driver will be sorted by both the target residency and exit latency in ascending order, but that's a different matter. Accordingly, drop the check in question along with the message printed when it triggers and the inaccurate comment preceding it. Fixes: 4bf944f3fcb6 ("cpuidle: Warn instead of bailing out if target residency check fails") Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle [ rjw: Subject fixup ] Link: https://patch.msgid.link/3444162.aeNJFYEL58@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c239f2d879abd069282bc4910f83f0a37475695f Author: Pablo Neira Ayuso Date: Tue Jun 23 12:56:55 2026 +0200 netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration [ Upstream commit 397c8300972f6e1486fd1afd99a044648a401cd5 ] On helper registration, the maximum number of expectations cannot go over NF_CT_EXPECT_MAX_CNT (255), but zero can be specified then nf_conntrack_expect_max applies. Turn zero into NF_CT_EXPECT_MAX_CNT otherwise, expectation LRU eviction on insertion is disabled. Moreover, expand this sanity check all expectation classes. This max_expecy policy is only tunable since userspace helpers are available, set Fixes: tag to the commit that adds such infrastructure. Remove the check for p->max_expected given this field must always be non-zero after this patch. Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e3b7789be80d9b9c0f9306d867499a1f9cedcc08 Author: Florian Westphal Date: Tue Jun 23 07:30:34 2026 +0200 netfilter: nft_ct: expectation timeouts are passed in milliseconds [ Upstream commit 6fb421bd07f156cdf0cdede062d31f1c21def326 ] Userspace passes '5000' in case user asks for 5 seconds. Allowing for sub-second expectation lifetimes makes sense to me. so fix up the kernel side instead of munging nft to send a value rounded up to next second. Also note that this violates nft convention of passing integers in network byte order, but we can't change this anymore. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f32e644fe36569ed653eb52f6c8d0a66bcc2a2d3 Author: Pablo Neira Ayuso Date: Mon Jun 22 21:35:18 2026 +0200 netfilter: nf_conntrack_expect: run expectation eviction with no helper [ Upstream commit be57dd9c1c1796e368582313af2b3849f78ac224 ] Run expectation eviction if no helper is specified to deal with the nft_ct expectation support. Cap the maximum expectation limit per master conntrack to NF_CT_EXPECT_MAX_CNT (255). Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3401ab813d27b8e8a1f0d5a9a8b936a4bec43726 Author: Pablo Neira Ayuso Date: Mon Jun 22 21:35:14 2026 +0200 netfilter: nf_conntrack_expect: store master_tuple in expectation [ Upstream commit 979c13114c0bb6ab9135e2c93e00c79c412aef09 ] Store master conntrack tuple in the expectation since exp->master might refer to a different conntrack when accessed from rcu read side lock area due to typesafe rcu rules. Fixes: 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7ec786f4230c2a9b2eaf97a2d45368933b49d2b2 Author: Pablo Neira Ayuso Date: Thu Jun 18 13:56:38 2026 +0200 netfilter: nf_conntrack_expect: use conntrack GC to reap expectations [ Upstream commit b8b09dc2bf35a00d4e0556b5d6308c7b917ebda2 ] This patch replaces the timer API by GC worker approach for expectations, as it already happened in many other subsystems. Use the existing conntrack GC worker to iterate over the local list of expectations in the master conntrack to reap expired expectations. Check IPS_HELPER_BIT to run GC for expectations, set it on for nft_ct expectation which nevers sets it. Hold the expectation spinlock while iterating over the master conntrack expectation list to synchronize with nf_ct_remove_expectations(). This also performs runtime packet path garbage collection through the expectation insertion and lookup functions while walking over one of the chains of the global expectation hashtables. Unconfirmed conntrack entries are skipped since ct->ext can be reallocated and dying are skipped since those will be gone soon. Set on IPS_HELPER_BIT if the helper ct extension is added, then the new GC worker does not need to bump the ct refcount to check if the ct->ext helper is available. This removes the extra bump on the refcount for expectation timers, this allows to remove several nf_ct_expect_put() calls after the unlink, after this update only refcount remains at 1 while on the expectation hashes. This patch implicitly addresses a race with the existing timer API allowing an expectation to access a stale exp->master pointer which has been already released when expectation removal loses races with an expiring timer, ie. timer_del() reporting false. Add a new NF_CT_EXPECT_DEAD flag to reap this expectation via GC. This is needed by nf_conntrack_unexpect_related() which is called in error paths to invalidate newly created expectations that has been added into the hashes. These expectactions cannot be inmediately released as GC or nf_ct_remove_expectations() could race to make it. On expectation insert, the runtime GC reaps stale expectations before checking the expectation limit set by policy. Set current timestamp in nf_ct_expect_alloc(), then add the expectation policy timeout (or custom timeout specified added on top of this) to specify the expectation lifetime. Fixes: bffcaad9afdf ("netfilter: ctnetlink: ensure safe access to master conntrack") Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 979c13114c0b ("netfilter: nf_conntrack_expect: store master_tuple in expectation") Signed-off-by: Sasha Levin commit 743209358ff8ea044e5cca540c7d38b1da71c17b Author: Pablo Neira Ayuso Date: Mon Jun 8 18:14:36 2026 +0200 netfilter: conntrack: check NULL when retrieving ct extension [ Upstream commit e3cd138e560764299965fba5ec5240281a7faca2 ] nf_ct_ext_find() might return NULL if ct extension is not found. Add also the null checks to: - nfct_help() - nfct_help_data() - nfct_seqadj() - nfct_nat() This is defensive, for safety reasons. nf_ct_ext_find() used to return NULL if the extension is stale for unconfirmed conntracks if the genid validation fails. Skip NULL check in nf_nat_inet_fn() given this is valid to be NULL for non-initialized ct nat extensions. While at it, fetch ct helper area in nf_ct_expect_related_report() only once and pass it on to other ancilliary functions. Replace WARN_ON() by WARN_ON_ONCE() in nf_ct_unlink_expect_report(). Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 979c13114c0b ("netfilter: nf_conntrack_expect: store master_tuple in expectation") Signed-off-by: Sasha Levin commit ae568b6f16e0425f6c50c166850d389a85c62856 Author: Pablo Neira Ayuso Date: Thu Jun 4 08:21:10 2026 +0200 netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker [ Upstream commit fe97fd540a03034a780224f24b0b2f0e21c9c763 ] Move the GRE specific cleanup to nf_conntrack_proto_gre.c to ensure that the .destroy callback for the pptp helper is still reachable by existing conntrack entries while pptp module is being removed. This is a preparation patch, no functional changes are intended. Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 979c13114c0b ("netfilter: nf_conntrack_expect: store master_tuple in expectation") Signed-off-by: Sasha Levin commit a1572284b14e5762cf821ee85f81dd9d27668cb7 Author: Pablo Neira Ayuso Date: Thu Jun 4 08:21:09 2026 +0200 netfilter: nf_conntrack_helper: dynamically allocate struct nf_conntrack_helper [ Upstream commit 6031487d4e273d7e7c8c7deea5061b7a9aaa9db3 ] Adapt all existing helpers to use a modified version of nf_ct_helper_init(), to dynamically allocate struct nf_conntrack_helper. Allocate expect_policy[] built-in into the helper to ensure this area is reachable after helper removal since a follow up patch adds refcount to track use of the nf_conntrack_helper structure from packet path so it remains around until last reference from ct helper extension is dropped. Export __nf_conntrack_helper_register() which allows to register nfnetlink_cthelper dynamically allocated helper. Adapt nfnetlink_cthelper to use the built-in expect_policy[]. This is a preparation patch to add packet path refcounting to helpers. Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 979c13114c0b ("netfilter: nf_conntrack_expect: store master_tuple in expectation") Signed-off-by: Sasha Levin commit 40c14ce49963b264414b2f4f85add383d84f7d5f Author: Qingshuang Fu Date: Tue Jun 23 10:31:06 2026 +0800 gpio: davinci: fix IRQ domain leak on devm_kzalloc failure [ Upstream commit 4e8eb6952aa6749726c6c3763ae0032a6332c24f ] In davinci_gpio_irq_setup(), after successfully creating an IRQ domain with irq_domain_create_legacy(), a subsequent devm_kzalloc() failure in the bank loop causes the function to return -ENOMEM without removing the IRQ domain. Unlike devm-managed resources, irq_domain_create_legacy() does not auto-clean up on probe failure, so the domain is leaked. Fix by calling irq_domain_remove() before returning on allocation failure. Fixes: b5cf3fd827d2 ("gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip") Signed-off-by: Qingshuang Fu Link: https://patch.msgid.link/20260623023106.117229-1-fffsqian@163.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c129b0185e707dce405968e21afccd5728b2ce63 Author: Florian Westphal Date: Mon Jun 15 20:10:44 2026 +0200 netfilter: nft_compat: ebtables emulation must reject non-bridge targets [ Upstream commit 9dbba7e694ec045f21ede2f892fb42b81b4e1692 ] xtables targets return netfilter verdicts: NF_ACCEPT, NF_DROP, and so on. ebtables targets return incompatible verdicts: EBT_ACCEPT, EBT_DROP, ... We cannot allow fallback to NFPROTO_UNSPEC. ebtables doesn't permit this since 11ff7288beb2 ("netfilter: ebtables: reject non-bridge targets") but that commit missed the nft_compat layer. Reported-by: Ren Wei Reported-by: Wyatt Feng Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2f71ca368ffdea0d5245f45d06ba8b31e13b6e6e Author: Runyu Xiao Date: Thu Jun 11 12:21:20 2026 +0800 netfilter: nft_synproxy: stop bypassing the priv->info snapshot [ Upstream commit 11d4bc4e26fb66040a5b5d95e9abf37deac2b1fc ] nft_synproxy_eval_v4() and nft_synproxy_eval_v6() already take a whole-object READ_ONCE() snapshot of the shared priv->info state before building the SYNACK reply, but nft_synproxy_tcp_options() still masks opts->options with priv->info.options from the live shared object. When a named synproxy object is updated concurrently with SYN traffic, the eval path can then mix mss and timestamp handling from the local snapshot with an options mask taken from a newer configuration, so one SYNACK no longer reflects a coherent synproxy configuration. Use info->options so nft_synproxy_tcp_options() stays on the same local snapshot that the eval path already copied from priv->info. Fixes: ee394f96ad75 ("netfilter: nft_synproxy: add synproxy stateful object support") Signed-off-by: Runyu Xiao Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 025a41e76b51fbc7b8eaa5bacbaa9621d00e6aa7 Author: Lorenzo Bianconi Date: Mon Jun 8 14:33:23 2026 +0200 netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() [ Upstream commit 84460b644329e25809b4a6d9279d6359d7fd8ebc ] Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset. Fixes: ab427db178858 ("netfilter: flowtable: Add IPIP rx sw acceleration") Signed-off-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit be52572c6d55f677ba76869d3c63805c0d4891a3 Author: Fernando Fernandez Mancera Date: Thu May 14 16:16:28 2026 +0200 netfilter: nf_conncount: prevent connlimit drops for early confirmed ct [ Upstream commit c8b6f36f766991e3ebebec6596daee4b04dcbc49 ] Commit 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too. Fixes: 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") Reported-by: Alejandro Olivan Alvarez Closes: https://lore.kernel.org/netfilter-devel/177349610461.3071718.4083978280323144323@eldamar.lan/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit eb14aba91163c33d8c99f9d7c06690e08b56a250 Author: Mathias Krause Date: Tue Apr 28 11:09:17 2026 +0200 netfilter: nf_nat: avoid invalid nat_net pointer use on failed nf_nat_init() [ Upstream commit 069cfe3de2a5e16069485893cd04665ab769c1d8 ] We ran into below KASAN splat, which is mostly uninteresting, beside for having nf_nat_register_fn() in the call chain as a cause for the offending access: ================================================================== BUG: KASAN: slab-out-of-bounds in nf_nat_register_fn+0x5f9/0x640 Read of size 8 at addr ffff890031e54c20 by task iptables/9510 CPU: 0 UID: 0 PID: 9510 Comm: iptables Not tainted 6.18.18-grsec-full-20260320181326 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: […] dump_stack_lvl+0xee/0x160 ffff88004117eeb8 […] print_report+0x6e/0x640 ffff88004117eee0 […] ? __phys_addr+0x8e/0x140 ffff88004117eef0 […] ? kasan_addr_to_slab+0x51/0xe0 ffff88004117ef08 […] ? complete_report_info+0xec/0x1c0 ffff88004117ef20 […] ? nf_nat_register_fn+0x5f9/0x640 ffff88004117ef48 […] kasan_report+0xbc/0x140 ffff88004117ef50 […] ? nf_nat_register_fn+0x5f9/0x640 ffff88004117ef90 […] nf_nat_register_fn+0x5f9/0x640 ffff88004117eff8 […] ? nf_nat_icmp_reply_translation+0x6e0/0x6e0 ffff88004117f070 […] nf_tables_register_hook.part.0+0xa0/0x220 ffff88004117f080 […] nf_tables_addchain.constprop.0+0x1054/0x1fc0 ffff88004117f0b8 […] ? nft_chain_lookup.part.0+0x4ce/0xac0 ffff88004117f130 […] ? nf_tables_abort+0x3d80/0x3d80 ffff88004117f190 […] ? nf_tables_dumpreset_obj+0x100/0x100 ffff88004117f1c8 […] ? nft_table_lookup.part.0+0x255/0x300 ffff88004117f310 […] ? nf_tables_newchain+0x21a4/0x2fa0 ffff88004117f358 […] nf_tables_newchain+0x21a4/0x2fa0 ffff88004117f360 […] ? nf_tables_addchain.constprop.0+0x1fc0/0x1fc0 ffff88004117f458 […] ? nla_get_range_signed+0x4a0/0x4a0 ffff88004117f488 […] ? lock_acquire+0x16f/0x320 ffff88004117f490 […] ? find_held_lock+0x3b/0xe0 ffff88004117f4b0 […] ? __nla_parse+0x45/0x80 ffff88004117f500 […] nfnetlink_rcv_batch+0xbca/0x19a0 ffff88004117f550 […] ? nfnetlink_net_exit_batch+0x120/0x120 ffff88004117f618 […] ? __sanitizer_cov_trace_switch+0x63/0xe0 ffff88004117f720 […] ? gr_acl_handle_mmap+0x1c4/0x320 ffff88004117f7c0 […] ? nla_get_range_signed+0x4a0/0x4a0 ffff88004117f7e8 […] ? gr_is_capable+0x6f/0xe0 ffff88004117f830 […] ? __nla_parse+0x45/0x80 ffff88004117f860 […] ? skb_pull+0x103/0x1a0 ffff88004117f880 […] nfnetlink_rcv+0x3db/0x4a0 ffff88004117f8b0 […] ? nfnetlink_rcv_batch+0x19a0/0x19a0 ffff88004117f8d8 […] ? netlink_lookup+0xe2/0x240 ffff88004117f900 […] netlink_unicast+0x74b/0xb00 ffff88004117f930 […] ? netlink_attachskb+0xb20/0xb20 ffff88004117f980 […] ? __check_object_size+0x3e/0xaa0 ffff88004117f998 […] ? security_netlink_send+0x51/0x160 ffff88004117f9c8 […] netlink_sendmsg+0xa03/0x1200 ffff88004117f9f8 […] ? netlink_unicast+0xb00/0xb00 ffff88004117fa70 […] ? netlink_unicast+0xb00/0xb00 ffff88004117fac8 […] ? ____sys_sendmsg+0xe2a/0x1040 ffff88004117faf8 […] ____sys_sendmsg+0xe2a/0x1040 ffff88004117fb00 […] ? kernel_recvmsg+0x300/0x300 ffff88004117fb60 […] ? reacquire_held_locks+0xe9/0x260 ffff88004117fbc8 […] ___sys_sendmsg+0x138/0x200 ffff88004117fbf8 […] ? do_recvmmsg+0x7e0/0x7e0 ffff88004117fc30 […] ? lockdep_hardirqs_on_prepare+0x101/0x1e0 ffff88004117fc50 […] ? lock_acquire+0x16f/0x320 ffff88004117fd20 […] ? lock_acquire+0x16f/0x320 ffff88004117fd58 […] ? find_held_lock+0x3b/0xe0 ffff88004117fd70 […] __sys_sendmsg+0x17a/0x260 ffff88004117fdc8 […] ? __sys_sendmsg_sock+0x80/0x80 ffff88004117fdf0 […] ? syscall_trace_enter+0x15e/0x2c0 ffff88004117fe98 […] do_syscall_64+0x7d/0x400 ffff88004117fec8 […] entry_SYSCALL_64_safe_stack+0x4a/0x60 ffff88004117fef8 ================================================================== The out-of-bounds report, though, is a red herring as it is for an access that shouldn't have happened in the first place. When nf_nat_init() fails to register its BPF kfuncs, it'll unwind and, among others, call unregister_pernet_subsys() to deregister its per-net ops. This makes the previously allocated net id available for reuse by the next caller of register_pernet_subsys(), in our case, synproxy. However, 'nat_net_id' will still hold the previously allocated value. If nf_nat.o gets build as a module, all this doesn't matter. A failed initialization routine makes the module fail to load and any dependent module won't be able to load either. However, if nf_nat.o is built-in, a failing init won't /completely/ make its functionality unavailable to dependent modules, namely the code and static data is still there, free to be called by modules like nft_chain_nat.ko. Case in point, nft_chain_nat registers hooks that'll call into nf_nat which, in our case, failed to initialize and therefore won't have a valid net id nor related net_nat object any more. Code in nf_nat, namely nf_nat_register_fn() and nf_nat_unregister_fn(), still making use of the reallocated net id, lead to a type confusion as the call to net_generic() will no longer return memory belonging to an object suited to fit 'struct nat_net' but 'struct synproxy_net' instead. The latter is only 24 bytes on 64-bit systems, much smaller than struct nat_net which is 176 bytes, perfectly explaining the OOB KASAN report. Detect and handle a failed nf_nat_init() by testing the 'nf_nat_hook' pointer which will be reset to NULL on initialization errors to prevent the usage of an invalid nat_net pointer. As this check is only needed when nf_nat.o is built-in, guard it by '#ifndef MODULE...'. Fixes: cbc1dd5b659f ("netfilter: nf_nat: Fix possible memory leak in nf_nat_init()") Signed-off-by: Mathias Krause Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1bb3b6a5c3c5cc814eae4ff0212fdced36f8bce9 Author: Bradley Morgan Date: Fri Jun 19 13:03:03 2026 +0000 bpf: Disable xfrm_decode_session hook attachment [ Upstream commit 12091470c6b4c1c14b2de12dcbae2ada6cb6d20b ] BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic. Fixes: 9e4e01dfd325 ("bpf: lsm: Implement attach, detach and execution") Signed-off-by: Bradley Morgan Link: https://lore.kernel.org/r/20260619130305.27779-1-include@grrlz.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d684b72dfbd320623ccaab0779aa841190488e7c Author: Chen Cheng Date: Fri Jun 19 12:10:13 2026 +0800 md/raid5: avoid R5_Overlap races while breaking stripe batches [ Upstream commit 55b77337bdd088c77461588e5ec094421b89911b ] KCSAN report a race in break_stripe_batch_list() vs. raid5_make_request() on sh->dev[i].flags (plain word write vs. atomic bit op).. and .. one possible scenario is: CPU1 CPU2 break_stripe_batch_list(sh1) -> handle sh2 -> lock(sh2) -> sh2->batch_head = NULL -> unlock(sh2) -> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags) -> wake_up_bit(sh2->dev[i].flags) raid5_make_request() -> add_all_stripe_bios(sh2) -> lock(sh2) -> stripe_bio_overlaps(sh2) returns true batch_head is NULL, so new bio overlap exist bio on sh2 -> true -> set_bit(R5_Overlap, sh2->dev[i].flags) -> unlock(sh2) -> wait_on_bit(sh2->dev[i].flags) -> sh2->dev[i].flags = sh1->dev[i].flags & ~R5_Overlap No wait_up_bit(), CPU2 could be wait_on_bit() forever... Fix by : - Expand the protect zone. - Use batch_head's device flag's snaphot when no held head_sh->stripe_lock. - Move sh/head_sh->batch_head = NULL to the end of protected zone , and , any concurrent add_all_stripe_bios() grabs sh->stripe_lock now either: - see batch_head != null, and , is rejected by stripe_bio_overlaps() under the lock (no R5_Overlap wait ) , or , - sees batch_head == NULL, only after dev[i].flags has already been set and the prior R5_Overlap waiters worken. KCSAN report: ================================================ BUG: KCSAN: data-race in break_stripe_batch_list / raid5_make_request write (marked) to 0xffff8e89c8117548 of 8 bytes by task 4042 on cpu 0: raid5_make_request+0xea0/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 __x64_sys_io_submit+0xf7/0x220 x64_sys_call+0x1907/0x1c60 do_syscall_64+0x130/0x570 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff8e89c8117548 of 8 bytes by task 4010 on cpu 5: break_stripe_batch_list+0x249/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 md_thread+0x15a/0x2d0 kthread+0x1e3/0x220 ret_from_fork+0x37a/0x410 ret_from_fork_asm+0x1a/0x30 value changed: 0x0000000000000019 -> 0x0000000000000099 --> R5_Overlap Fixes: fb642b92c267 ("md/raid5: duplicate some more handle_stripe_clean_event code in break_stripe_batch_list") Signed-off-by: Chen Cheng Link: https://patch.msgid.link/20260619041013.1207148-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 4465211d195d81df6e9e513bf308c8ca5d13f05a Author: Chen Cheng Date: Thu Jun 18 21:47:48 2026 +0800 md/raid5: use stripe state snapshot in break_stripe_batch_list() [ Upstream commit 9b249f5ffbeda24c57e6c56ed896c5ca4fc70549 ] The patch just suppress KCSAN noise. No functional change. RAID-5 can group multi full-stripe-write aka stripe_head into a batch aka batch_list, with one head_sh leading them. Call break_stripe_batch_list() when the batch is finished, or, a stripe has to be dropped out of the batch. break_stripe_batch_list() reads stripe state several times while request paths can update thost state words concurrently with lockless bitops, which reported by KCSAN. Use a snapshot to guarantees that the value used for warning, copying, and handle checks is internally consistent at current read moment. KCSAN report: ============================================== BUG: KCSAN: data-race in __add_stripe_bio / break_stripe_batch_list write (marked) to 0xffff8e89d4f0b988 of 8 bytes by task 4323 on cpu 3: __add_stripe_bio+0x35e/0x400 raid5_make_request+0x6ac/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 read to 0xffff8e89d4f0b988 of 8 bytes by task 4290 on cpu 4: break_stripe_batch_list+0x3ce/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 Signed-off-by: Chen Cheng Link: https://patch.msgid.link/20260618134748.1168360-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Stable-dep-of: 55b77337bdd0 ("md/raid5: avoid R5_Overlap races while breaking stripe batches") Signed-off-by: Sasha Levin commit a668fa160247d7bbe921548cb845f607b8b9305f Author: Kuniyuki Iwashima Date: Fri Jun 19 21:27:20 2026 +0000 ipv4: fib: Don't ignore error route in local/main tables. [ Upstream commit b72f0db64205d9ce462038ba995d5d31eff32dc1 ] When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour. Fixes: f4530fa574df ("ipv4: Avoid overhead when no custom FIB rules are installed.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260619212753.3367244-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5bd84c6cd77dee5503ecb9f0f4f35c4f992e347 Author: Jakub Kicinski Date: Fri Jun 19 12:15:38 2026 -0700 eth: bnxt: improve the timing of stats [ Upstream commit 40529e58629baa9ce72143cb46cf1b3d2ca0d465 ] Kernel selftests wait 1.25x of the promised stats refresh time (as read from ethtool -c). bnxt reports 1sec by default, but the stats update process has two steps. First device DMAs the new values, then the service task performs update in full-width SW counters. So the worst case delay is actually 2x. Note that the behavior is different for ring stats and port stats. Port stats are fetched synchronously by the service worker, so there's no risk of doubling up the delay there. The problem of stale stats impacts not only tests but real workloads which monitor egress bandwidth of a NIC. The inaccuracy causes double counting in the next cycle and spurious overload alarms. Try to read from the DMA buffer more aggressively, to mitigate timing issues between DMA and service task. The SW update should be cheap. Fixes: 51f307856b60 ("bnxt_en: Allow statistics DMA to be configurable using ethtool -C.") Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260619191538.104165-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6428634f7a0b7878144b4925c37856bef3224967 Author: Xiang Mei Date: Thu Jun 18 21:53:34 2026 -0700 ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). [ Upstream commit 46c3b8191aad3d032776bf3bebf03efdf5f4b905 ] fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad ("ipv6: Fix null-ptr-deref in fib6_mtu()."). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410 Fixes: c0b220cf7d80 ("ipv6: Refactor exception functions") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260619045334.2427073-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c89da3baa2b1f269178afa87dc30479b8535776 Author: Gil Portnoy Date: Fri Jun 19 08:25:46 2026 +0900 ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE [ Upstream commit 0c054227479ed7e36ebccb3a558bc0ef698264f6 ] conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O). Fixes: aa7253c2393f ("ksmbd: fix memory leak in smb2_handle_negotiate") Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 03ae998ae6237d6403d7a8b91cecccf586d0bade Author: Yiyang Chen Date: Thu Jun 18 10:18:44 2026 +0000 selftests/bpf: Cover small conntrack opts error writes [ Upstream commit 38ba6d43af3844ae502092ee9dcc47214e82acb8 ] Add a conntrack kfunc regression check for opts__sz values that do not cover opts->error. The BPF program initializes opts->error with a guard value, calls the lookup and allocation kfuncs with opts__sz set to sizeof(opts->netns_id), and verifies that the guard is still intact after the kfunc returns NULL. Without the conntrack wrapper guard, the kfunc error path overwrites that guard with -EINVAL even though the verifier checked only the first four bytes of the options object. Fixes: b4c2b9593a1c ("net/netfilter: Add unstable CT lookup helpers for XDP and TC-BPF") Fixes: d7e79c97c00c ("net: netfilter: Add kfuncs to allocate and insert CT") Signed-off-by: Yiyang Chen Link: https://lore.kernel.org/r/007dfd0341cd84560e4795a2a951cc56d4adff1d.1781765747.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit dd74c80203842a21b2ebb9f70d1260d9aa20fa05 Author: Yiyang Chen Date: Thu Jun 18 10:18:43 2026 +0000 bpf: Guard conntrack opts error writes [ Upstream commit 6f6183a39533d727deaa5061cadae6dd9e6744d0 ] The conntrack lookup and allocation kfuncs take an opts pointer together with an opts__sz argument. The verifier checks only the memory range described by opts__sz, but the wrappers unconditionally write opts->error whenever the internal lookup or allocation helper returns an error. For an invalid size smaller than the end of opts->error, that write can land outside the verifier-checked range. Keep returning NULL for invalid arguments, but only report the error through opts->error when the supplied size includes the field. This preserves error reporting for the supported 12-byte and 16-byte layouts, and for other invalid sizes that still include opts->error. Fixes: b4c2b9593a1c ("net/netfilter: Add unstable CT lookup helpers for XDP and TC-BPF") Fixes: d7e79c97c00c ("net: netfilter: Add kfuncs to allocate and insert CT") Signed-off-by: Yiyang Chen Link: https://lore.kernel.org/r/9535e781fe14449b1d4e9bbc3baa7566a93bf512.1781765747.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bb3e624808c981fe881cb79037be63e680ed7d38 Author: Stepan Ionichev Date: Mon May 11 08:27:03 2026 +0500 rtc: msc313: fix NULL deref in shared IRQ handler at probe [ Upstream commit a369f48be8de426a7d2bca18dbd46c2ad1138803 ] msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and &pdev->dev as the cookie, but platform_set_drvdata() is only called later after the clock setup. With a shared IRQ line, another device on the same line can trigger the handler in that window. The handler does dev_get_drvdata() on the cookie, gets NULL, and dereferences priv->rtc_base in interrupt context. Pass priv as the cookie directly so the handler reads it from dev_id without the lookup, removing the dependency on probe order. Fixes: be7d9c9161b9 ("rtc: Add support for the MSTAR MSC313 RTC") Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260511032703.48262-1-sozdayvek@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 5f2cfe30af5a481b46d5eaea6a500e475b97e348 Author: Dima Ruinskiy Date: Fri Apr 17 13:43:30 2026 +0300 e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor Lake [ Upstream commit 578294b8b60d2c630991f221838f9ec61ae89df0 ] Commit 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1") disabled K1 by default on Meteor Lake and newer systems due to packet loss observed on various platforms. However, disabling K1 caused an increase in power consumption. To mitigate this, reconfigure the PLL clock gate value so that K1 can remain enabled without incurring the additional power consumption. Re-enable K1 by default, but keep the private flag to support disabling it via ethtool. Additionally, introduce a DMI quirk table, so that K1 may be disabled by default on known problematic systems. Currently, this includes the Dell Pro 16 Plus, where the issue has been reported to persist despite the changes to the PLL lock timeout. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220954 Link: https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250623/048860.html Link: https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20260330/054059.html Signed-off-by: Dima Ruinskiy Co-developed-by: Vitaly Lifshits Signed-off-by: Vitaly Lifshits Fixes: 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1") Tested-by: Moriya Kadosh Tested-by: Todd Brandt Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 939756efe5056cc78cba7878179652ae34c0579d Author: Mohamed Khalfella Date: Wed May 6 15:41:23 2026 -0700 i40e: Fix i40e_debug() to use struct i40e_hw argument [ Upstream commit 798f94603eb0737033861efd320a9159f382a7c5 ] i40e_debug() macro takes struct i40e_hw *h as first argument. But the macro body uses hw instead of h. This has been working so far because hw happens to be the name of the variable in the context where the macro is expanded. Fix the macro to use the passed argument. Fixes: 5dfd37c37a44 ("i40e: Split i40e_osdep.h") Signed-off-by: Mohamed Khalfella Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 40c68e35e700f43197145e3a1d96c298a28aacfe Author: ZhaoJinming Date: Fri May 29 13:37:33 2026 +0800 ice: dpll: fix memory leak in ice_dpll_init_info error paths [ Upstream commit 20da495f2df0fd4adc435d3d621366e8c807539c ] Several error return paths in ice_dpll_init_info() directly return without freeing previously allocated resources, causing memory leaks: - When de->input_prio allocation fails, d->inputs is leaked - When dp->input_prio allocation fails, d->inputs and de->input_prio are leaked - When ice_get_cgu_rclk_pin_info() fails, all previously allocated inputs/outputs/input_prio are leaked - When ice_dpll_init_pins_info(RCLK_INPUT) fails, same resources are leaked Fix this by jumping to the deinit_info label which properly calls ice_dpll_deinit_info() to free all allocated resources. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Signed-off-by: ZhaoJinming Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 17c0a9db05e3fa93ecf49a143e1316c6ea0422b2 Author: ZhaoJinming Date: Fri May 29 13:37:32 2026 +0800 ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info [ Upstream commit a903afff66d7379c6ece42bd18b2a17f4c79d1a9 ] ice_dpll_deinit_info() calls kfree() on several pf->dplls fields (inputs, outputs, eec.input_prio, pps.input_prio) but does not set the pointers to NULL afterward. This leaves dangling pointers in the pf->dplls structure. While not currently exploitable through existing code paths, this is unsafe because: 1. If ice_dpll_init_info() is called again after a deinit (e.g. during driver recovery), and a subsequent allocation within init fails, the error path will jump to deinit_info and call ice_dpll_deinit_info() again. Since some pointers still hold the old freed addresses, this would result in a double-free. 2. Any future code that checks these pointers before use or after free would be unprotected against use-after-free. Follow the common kernel convention of setting pointers to NULL after kfree() so that: - kfree(NULL) is a safe no-op, preventing double-free - NULL checks on these pointers become meaningful This is a preparatory fix for a subsequent patch that routes additional error paths in ice_dpll_init_info() to the deinit_info label. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Signed-off-by: ZhaoJinming Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 19ec35b79913f6c43bea23d8d117415786a1cdb8 Author: John Madieu Date: Sat Apr 25 15:49:59 2026 +0000 rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on cleanup [ Upstream commit 1afe4f19d6ad404621150f0e91feeccf12fb1037 ] isl1208_setup_irq() calls enable_irq_wake() after a successful IRQ request, but the driver has no remove path that balances it. The driver is devm-only, so on unbind devm releases the IRQ - but enable_irq_wake() is not undone by IRQ release, so the wake count for that IRQ stays incremented. Each rebind therefore leaks one wake reference; the leak doubles for the chip variant that has a separate evdet IRQ, since isl1208_setup_irq() is then called twice during probe. Register a devm action that calls disable_irq_wake() per IRQ. While at it, check enable_irq_wake()'s return value: on failure, propagate the error rather than silently registering a disable action for an IRQ whose wake state was never enabled. Fixes: 9ece7cd833a3 ("rtc: isl1208: Add "evdet" interrupt source for isl1219") Signed-off-by: John Madieu Link: https://patch.msgid.link/20260425154959.2796261-3-john.madieu.xa@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6c70914ab629957ec0f60be11d642ad7b01c17b6 Author: Marcin Szycik Date: Wed Apr 8 16:14:29 2026 +0200 ice: call netif_keep_dst() once when entering switchdev mode [ Upstream commit c0d00c882bc432990d57052a659f9a8bd1f60687 ] netif_keep_dst() only needs to be called once for the uplink VSI, not once for each port representor. Move it from ice_eswitch_setup_repr() to ice_eswitch_enable_switchdev(). Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path") Signed-off-by: Marcin Szycik Signed-off-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4f13a0a479b55d23e3f0b111efdb24b379bf80f0 Author: Lukasz Czapnik Date: Fri Mar 27 08:22:35 2026 +0100 ice: fix AQ error code comparison in ice_set_pauseparam() [ Upstream commit 2bf7744bc3221a63b95c76c94eab1dad832fa401 ] Fix unreachable code: the conditionals in ice_set_pauseparam() used the bitwise-AND operator suggesting aq_failures is a bitmap, but it is actually an enum, making the third condition logically unreachable. Replace the if-else ladder with a switch statement. Also move the aq_failures initialization to the variable declaration and remove the redundant zeroing from ice_set_fc(). Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Signed-off-by: Lukasz Czapnik Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b1fc5bafbc5f84df457b6f987ac993e0802f8d93 Author: Dawid Osuchowski Date: Fri Mar 27 08:22:32 2026 +0100 ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs() [ Upstream commit ebbe8868cf473f698e0fbaf436d2618b2bcda806 ] Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using ice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which aligns behavior with the ice_reset_vf() function. Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset Fixes: da62c5ff9dcd ("ice: Add support for per VF ctrl VSI enabling") Signed-off-by: Dawid Osuchowski Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0f9278b22cda6fd2525049930157b79b4036b4ef Author: Nuoqi Gui Date: Wed Jun 17 23:20:20 2026 +0800 bpf: Preserve pointer spill metadata during half-slot cleanup [ Upstream commit 3a354149bceacadbcf7d7b4766f5ef26a85892ab ] __clean_func_state() cleans dead stack slots in 4-byte halves. When the high half of a STACK_SPILL slot is dead and the low half remains live, cleanup converts the live low half to STACK_MISC or STACK_ZERO and clears the saved spilled_ptr metadata. That conversion is safe only for scalar spills. For a pointer spill, this metadata clear lets a later 32-bit fill from the still-live half avoid the normal non-scalar register-fill check and be treated as an ordinary scalar stack read. Leave non-scalar spill slots intact in this half-live shape. This is conservative for pruning and preserves the existing check_stack_read_fixed_off() rejection path for partial fills from pointer spills. Fixes: be23266b4a08 ("bpf: 4-byte precise clean_verifier_state") Acked-by: Eduard Zingerman Signed-off-by: Nuoqi Gui Link: https://lore.kernel.org/r/20260617-f01-06-half-slot-pointer-spill-v2-1-42b9cdc3cf64@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 233170ad54d339a6e21d7bfe5113f1e14227c453 Author: Koichiro Den Date: Wed May 13 11:49:14 2026 +0900 PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via ntb_db_event() [ Upstream commit 91fb4488cd615a39360bc4160a10cb3236189ba1 ] ntb_db_event() expects the vector number to be relative to the first doorbell vector starting at 0. pci-epf-vntb reserves vector 0 for link events and uses higher vector indices for doorbells. By passing the raw slot index to ntb_db_event(), it effectively assumes that doorbell 0 maps to vector 1. However, because the host uses a legacy slot layout and writes doorbell 0 into the third slot, doorbell 0 ultimately appears as vector 2 from the NTB core perspective. Adjust pci-epf-vntb to: - skip the unused second slot, and - report doorbells as 0-based vectors (DB#0 -> vector 0). This change does not introduce a behavioral difference until .db_vector_count()/.db_vector_mask() are implemented, because without those callbacks NTB clients effectively ignore the vector number. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-4-den@valinux.co.jp Signed-off-by: Sasha Levin commit 93a85a6aca1974f7af89accc5a0220e85d64095a Author: Koichiro Den Date: Wed May 13 11:49:13 2026 +0900 PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic context [ Upstream commit 18355c1e986582aaff2c488b1a2ce79bac8f3cf9 ] The NTB .peer_db_set() callback may be invoked from atomic context. pci-epf-vntb currently calls pci_epc_raise_irq() directly, but pci_epc_raise_irq() may sleep (it takes epc->lock). Avoid sleeping in atomic context by coalescing doorbell bits into an atomic64 pending mask and raising MSIs from a work item. Limit the amount of work per run to avoid monopolizing the workqueue under a doorbell storm. Clear stale pending bits before enabling the work item and after disabling it during cleanup. Also mask requested doorbells against the currently valid doorbell mask before queueing work, and iterate the pending u64 with __ffs64() so high doorbell bits are handled correctly. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-3-den@valinux.co.jp Stable-dep-of: 91fb4488cd61 ("PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via ntb_db_event()") Signed-off-by: Sasha Levin commit 528cfbcc47bbc84d036d6669585e62c75628f59e Author: Koichiro Den Date: Wed May 13 11:49:12 2026 +0900 PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset [ Upstream commit 6a7db4fcc6c23b1d25e676400d764bdcb7dc1ccb ] vntb_epf_peer_db_set() raises an MSI interrupt to notify the RC side of a doorbell event. pci_epc_raise_irq(..., PCI_IRQ_MSI, interrupt_num) takes a 1-based MSI interrupt number. The ntb_hw_epf driver reserves MSI #1 for link events, so doorbells would naturally start at MSI #2 (doorbell bit 0 -> MSI #2). However, pci-epf-vntb has historically applied an extra offset and mapped doorbell bit 0 to MSI #3. This matches the legacy behavior of ntb_hw_epf and has been preserved since commit e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP"). This offset has not surfaced as a functional issue because: - ntb_hw_epf typically allocates enough MSI vectors, so the off-by-one still hits a valid MSI vector, and - ntb_hw_epf does not implement .db_vector_count()/.db_vector_mask(), so client drivers such as ntb_transport effectively ignore the vector number and schedule all QPs. Correcting the MSI number would break interoperability with peers running older kernels. Document the legacy offset to avoid confusion when enabling per-db-vector handling. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-2-den@valinux.co.jp Stable-dep-of: 91fb4488cd61 ("PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via ntb_db_event()") Signed-off-by: Sasha Levin commit a58543f1e1cc6edb28c13d5b9aabd04005aa45a2 Author: Manivannan Sadhasivam Date: Tue Apr 7 18:14:21 2026 +0530 PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0 [ Upstream commit d1db6d7c2485ee475a04d8354fbb5b26ea10d978 ] epf_ntb->db_count value should be within 1 to MAX_DB_COUNT. Current code only checks for the upper bound, while the lower bound is unchecked. This can cause a lot of issues in the driver if the user passes 'db_count' as 0. Add a check for 0 also. While at it, remove the redundant 'db_count' variable from epf_ntb_configure_interrupt(). Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260407124421.282766-3-mani@kernel.org Signed-off-by: Sasha Levin commit 750dd7546de3e5a765b530cab002ae7be21fef64 Author: Manivannan Sadhasivam Date: Tue Apr 7 18:14:20 2026 +0530 PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0 [ Upstream commit 33bd1ea748bc897c4d13437284e08c658e8d1340 ] epf_ntb->db_count value should be within 1 to MAX_DB_COUNT. Current code only checks for the upper bound, while the lower bound is unchecked. This can cause a lot of issues in the driver if the user passes 'db_count' as 0. Add a check for 0 also. While at it, remove the redundant 'db_count' assignment. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Koichiro Den Reviewed-by: Frank Li Link: https://patch.msgid.link/20260407124421.282766-2-mani@kernel.org Signed-off-by: Sasha Levin commit 937f77a7963681254e48f30a369b55a129f9854e Author: Ahmad Fatoum Date: Wed Jun 17 16:47:53 2026 +0200 ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8 [ Upstream commit cf81b260916c92cf610c907d41627a175e86e37d ] When this driver was first added, it accepted rates of 24.56 MHz and 22.572 MHz for the MCLK when PLL bypass is enabled. These rates seem to have no basis in the datasheets and were thus replaced with 45.1584 MHz and 49.152 MHz, respectively, in commit e7ab858390f2 ("ASoC: cs530x: Correct MCLK reference frequency values"). While the new rates are indeed correct for the CS4xxx ICs[0][1][2][3], they are incorrect for the CS530x ICs the driver was originally written to support as the MCLK frequencies are halved there[4][5][6]. Fix this by checking against the correct type-appropriate rates. While at it, drop the CS530X_SYSCLK_REF_* macros. They arguably confuse more than they help, especially as they are not applicable to the cs5302/4/8. [0]: https://statics.cirrus.com/pubs/proDatasheet/CS4282P_DS1318F1.pdf [1]: https://statics.cirrus.com/pubs/proDatasheet/CS4302P_DS1315F1.pdf [2]: https://statics.cirrus.com/pubs/proDatasheet/CS4304P_DS1316F1.pdf [3]: https://statics.cirrus.com/pubs/proDatasheet/CS4308P_DS1317F1.pdf [4]: https://statics.cirrus.com/pubs/proDatasheet/CS5302P_DS1312F1.pdf [5]: https://statics.cirrus.com/pubs/proDatasheet/CS5304P_DS1313F1.pdf [6]: https://statics.cirrus.com/pubs/proDatasheet/CS5308P_DS1314F1.pdf Fixes: 2884c29152c0 ("ASoC: cs530x: Support for cs530x ADCs") Signed-off-by: Ahmad Fatoum Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260617-cs530x-mclk-v1-1-0215b5f1a0a4@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 50456f445feeeaf05eceb04663217c1040a4dade Author: Zhan Xusheng Date: Mon Jun 22 16:11:36 2026 +0800 erofs: handle 48-bit blocks_hi for compressed inodes [ Upstream commit 803d09a554055aba160a62abd1e4b1260b899dc1 ] Combine i_nb.blocks_hi with i_u.blocks_lo when computing inode->i_blocks for compressed inodes, mirroring the startblk_hi handling for unencoded inodes a few lines above. Also evaluate the shift in u64 to avoid truncation. Fixes: efb2aef569b3 ("erofs: add encoded extent on-disk definition") Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata") Reviewed-by: Gao Xiang Signed-off-by: Zhan Xusheng Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 4137e1ecec9c8cb6c4fcee28ffabbbc7409eb7fb Author: Xiang Mei Date: Mon Jun 15 11:47:37 2026 -0700 drm/edid: fix OOB read in drm_parse_tiled_block() [ Upstream commit faaa1e1155833e7d4ce7e3cfaf64c0d636b190db ] drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740) Fixes: 40d9b043a89e ("drm/connector: store tile information from displayid (v3)") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260615184737.899892-1-xmei5@asu.edu Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 6558811274c8c7993fa6da8fa9c0ae9aeedf7006 Author: Ruoyu Wang Date: Sat Jun 20 23:53:19 2026 +0800 gpiolib: initialize return value in gpiochip_set_multiple() [ Upstream commit 99dfa46baba29513d1094c8f30bc86c6ef88543a ] gpiochip_set_multiple() falls back to setting lines one by one when the chip does not provide set_multiple(). If the fallback path receives an empty mask, the loop is skipped and ret is returned without being initialized. Initialize ret to 0 so an empty mask is treated as a successful no-op. Fixes: 9b407312755f ("gpiolib: rework the wrapper around gpio_chip::set_multiple()") Signed-off-by: Ruoyu Wang Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20260620155319.79994-1-ruoyuw560@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 7dba66caf98e75c76980f127270e378e533c2ea3 Author: Bartosz Golaszewski Date: Thu Jun 18 10:45:12 2026 +0200 power: sequencing: fix ABBA deadlock in pwrseq_device_unregister() [ Upstream commit 2d5a7d406ecece5837af1e278ffbbf6c0315560a ] The pwrseq core takes three locks in consistent order everywhere: pwrseq_sem -> pwrseq->rw_lock -> pwrseq->state_lock pwrseq_get() -> pwrseq_match_device() takes pwrseq_sem for reading, then rw_lock for reading. pwrseq_power_on()/pwrseq_power_off() take rw_lock for reading and then state_lock. pwrseq_device_unregister() is the only exception, it takes: state_lock, then rw_lock for writing and finally pwrseq_sem for writing. This created two potential ABBA deadlock situations that sashiko pointed out. - pwrseq_power_on/off() take rw_lock for reading then state_lock, while pwrseq_unregister() takes state_lock then rw_lock for writing - pwrseq_get() takes pwrseq_sem for reading then rw_lock for reading, while pwrseq_unregister() takes rw_lock for writing then pwrseq_sem for writing Reorder the unregister path to taking pwrseq_sem for writing -> rw_lock for writing and drop the state_lock entirely. This is safe as enable_count is only ever written under rw_lock held for read (via pwrseq_unit_enable()/disable(), reached only from pwrseq_power_on/off()), so holding rw_lock for writing already excludes every other writer and reader and the active-users WARN() stays race-free without state_lock. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Closes: https://sashiko.dev/#/patchset/20260616151049.1705503-1-vulab%40iscas.ac.cn Link: https://patch.msgid.link/20260618-pwrseq-abba-deadlock-v1-1-943a3fd81c06@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit b584f107ab90222bd825dcb4c5977326ff684109 Author: Amery Hung Date: Thu Jun 18 23:35:19 2026 -0700 bpf: Fix effective prog array index with BPF_F_PREORDER [ Upstream commit f08aaee3152d0dfc578b3f2586932d82062701dd ] replace_effective_prog() and purge_effective_progs() located the slot in the effective array by walking the program hlist and counting entries linearly. That count does not match the array layout: compute_effective_ progs() places BPF_F_PREORDER programs at the front (ancestor cgroup first, attach order within a cgroup) and the rest after them (descendant cgroup first). So when a preorder program is present, the linear hlist position no longer equals the program's index in the effective array. For replace_effective_prog() (bpf_link_update()) this overwrote the wrong slot, corrupting the effective order. For purge_effective_progs(), it could dummy out a slot belonging to a different program and leave the detached program in the array while bpf_prog_put() drops its reference, i.e. a use-after-free. Fix both by replaying compute_effective_progs()'s placement (including the per-cgroup preorder reversal) in a shared effective_prog_pos() helper. Identify the entry by its struct bpf_prog_list pointer rather than by (prog, link) value, so the lookup resolves to exactly the attachment the syscall selected even when the same bpf_prog is attached to several cgroups in the hierarchy. Fixes: 4b82b181a26c ("bpf: Allow pre-ordering for bpf cgroup progs") Signed-off-by: Amery Hung Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260619063520.2690547-2-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d977b2aff9f738a973e39139a6935af35b4062bd Author: Thiébaud Weksteen Date: Thu Jun 18 14:09:33 2026 +1000 bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check [ Upstream commit 8405c4626460503027461652f96d8bb10c2a9173 ] When struct prog_assoc_struct_ops was added, BPF_PROG_ASSOC_STRUCT_OPS_LAST_FIELD referenced prog_fd instead of the actual last field, flags. Fixes: b5709f6d26d6 ("bpf: Support associating BPF program with struct_ops") Signed-off-by: Thiébaud Weksteen Reviewed-by: Jakub Sitnicki Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260618040934.4113938-1-tweek@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8b996c5555750c5538d7aca249bd3d6bb6094580 Author: Avinash Duduskar Date: Thu Jun 18 04:17:19 2026 +0530 bpf: zero-initialize the fib lookup flow struct [ Upstream commit 0dfcb68a6a5ac517b22dff6a1f01cb4f126dfc57 ] bpf_ipv4_fib_lookup() and bpf_ipv6_fib_lookup() build the flow key on the stack with a bare "struct flowi4 fl4;" / "struct flowi6 fl6;" and fill it field by field, but never set flowi4_l3mdev / flowi6_l3mdev. On the non-DIRECT path the lookup goes through the fib rules whenever the netns has custom rules, which a VRF installs: bpf_ipv4_fib_lookup() -> fib_lookup() -> __fib_lookup() -> l3mdev_update_flow() reads !fl->flowi_l3mdev -> fib_rules_lookup() -> fib_rule_match() -> l3mdev_fib_rule_match() uses fl->flowi_l3mdev l3mdev_update_flow() resolves the l3mdev master from the ingress device only while the field is still zero. Left at a nonzero stack value the resolution is skipped, and l3mdev_fib_rule_match() then tests that value as an ifindex, so the VRF master is not resolved and the rule fails to match: an ingress enslaved to a VRF can fail to select its table. FIB rules matching on an L3 master device (l3mdev_fib_rule_iif_match()/ _oif_match()) read the same value, so an "ip rule iif/oif " mismatches the same way. Zero-initialize the whole flow struct rather than adding one more field assignment, so any flowi field added later is covered too. ip_route_input_slow() likewise zeroes the field before its input lookup. CONFIG_INIT_STACK_ALL_ZERO masks this by default, but it depends on compiler support (CC_HAS_AUTO_VAR_INIT_ZERO), so INIT_STACK_NONE builds, including older toolchains that fall back to it, are exposed. Built with INIT_STACK_ALL_PATTERN, a plain bpf_fib_lookup (no VLAN, no DIRECT) over a VRF slave whose destination is routed only in the VRF table returns BPF_FIB_LKUP_RET_NOT_FWDED, and resolves with this patch. On the default config the lookup succeeds either way, so ordinary testing does not catch the bug. Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Signed-off-by: Avinash Duduskar Reviewed-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/20260617224719.1428599-1-avinash.duduskar@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7faf89ed5b4c248608ff7471515603970dc331be Author: Yichong Chen Date: Wed Jun 17 17:01:17 2026 +0800 bpftool: Fix vmlinux BTF leak in cgroup commands [ Upstream commit bda6a7308ef8e79cfbb7d09e48e1c7ffaa522269 ] bpftool cgroup show and tree call libbpf_find_kernel_btf() to resolve attach_btf names, but never release the returned BTF object. For cgroup tree, do_show_tree_fn() is called once for each cgroup visited by nftw(). When more than one cgroup has attached programs, each callback overwrites btf_vmlinux with a new object and loses the previous allocation. Load vmlinux BTF only once during a tree walk and release it when cgroup show or tree completes. Reset btf_vmlinux_id at the same time so batch mode starts with clean state. Fixes: 596f5fb2ea2a ("bpftool: implement cgroup tree for BPF_LSM_CGROUP") Signed-off-by: Yichong Chen Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/24357C69B4405079+20260617090117.280222-1-chenyichong@uniontech.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 89cf4d0c71a2c68c7190228309c399433ef6c4c7 Author: Sun Jian Date: Wed Jun 17 17:35:56 2026 +0800 bpf: Fix partial copy of non-linear test_run output [ Upstream commit b5f3534268e3f91c9d3e9dc79ee5a32555880ee9 ] For non-linear test_run output, bpf_test_finish() derives the linear data copy length from copy_size - frag_size. This only matches the linear data length when copy_size is the full packet size. When userspace provides a short data_out buffer, copy_size is clamped to that buffer size. If copy_size is smaller than frag_size, the computed length becomes negative and bpf_test_finish() returns -ENOSPC before copying the packet prefix or updating data_size_out. Compute the linear data length from the packet layout instead, and clamp the linear copy length to copy_size. This preserves the expected partial-copy semantics: return -ENOSPC, copy the packet prefix that fits in data_out, and report the full packet length through data_size_out. Fixes: 7855e0db150ad ("bpf: test_run: add xdp_shared_info pointer in bpf_test_finish signature") Signed-off-by: Sun Jian Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260617093557.63880-2-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit db8f1dcf5950b91886b9df4270bc816370d292c1 Author: Nuoqi Gui Date: Thu Jun 18 01:50:26 2026 +0800 bpf: Fix stack slot index in nospec checks [ Upstream commit d1d53aa30ab3b5ae89161c9cc840b3f7489ad386 ] check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[]. Fixes: 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") Acked-by: Luis Gerhorst Reviewed-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Signed-off-by: Nuoqi Gui Link: https://lore.kernel.org/r/20260618-f01-11-stack-nospec-slot-index-v3-1-780297041721@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9242939dd6d9e0b7dd840ee5c8f0ebb99f9a382c Author: Ronan Dalton Date: Fri May 8 15:24:49 2026 +1200 rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231 [ Upstream commit a091e1ba3b68cabc9caedafc6f81d9fe9b3b2200 ] Prior to commit 48458654659c ("rtc: ds1307: remove clear of oscillator stop flag (OSF) in probe"), the oscillator stop flag (OSF) bit was checked during device probe for the ds1337, ds1339, ds1341, and ds3231 chips; if it was set, it would be cleared and a warning would be logged saying "SET TIME!". Since that commit, the OSF bit is no longer cleared, but the warning is still printed. Directly following that commit, there was no way to get rid of this warning because nothing cleared the OSF bit on these chips. The commit associated with the previous commit, 523923cfd5d6 ("rtc: ds1307: handle oscillator stop flag (OSF) for ds1341"), made proper use of the OSF when getting and setting the time in the RTC. However, the other RTC variants ds1337, ds1339 and ds3231 didn't have a corresponding change made. Given that the OSF bit is no longer cleared at probe time when it is set, the remaining three chips should have the same handling as the ds1341 chip has for the OSF bit. Fix the issue on the ds1337, ds1339 and ds3231 chips by applying the same logic as the ds1341 has to these chips. Note that any devices brought up between the first referenced commit and this one may begin mistrusting the time reported by the RTC until it is set again, if the bit was never explicitly cleared. Note that only the ds1339 was tested with this change, but the datasheets for the other chips contain essentially identical descriptions of the OSF bit so the same change should work. Signed-off-by: Ronan Dalton Cc: linux-rtc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Alexandre Belloni Cc: Tyler Hicks Cc: Sasha Levin Cc: Meagan Lloyd Cc: Rodolfo Giometti Cc: Chris Packham Fixes: 48458654659c ("rtc: ds1307: remove clear of oscillator stop flag (OSF) in probe") Reviewed-by: Meagan Lloyd Reviewed-by: Tyler Hicks Link: https://patch.msgid.link/20260508032518.3696705-2-ronan.dalton@alliedtelesis.co.nz Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit fc4f78e8f03442cc76e91b182cbeb12bfa22d975 Author: Antoni Pokusinski Date: Wed Apr 15 18:06:11 2026 +0200 rtc: abx80x: fix the RTC_VL_CLR clearing all status flags [ Upstream commit 419719c514252a2dbb2e2976f564c83417dd6d0a ] The RTC_VL_CLR ioctl intends to clear only the battery low flag (BLF), however the current implementation writes 0 to the status register, clearing all status bits. Fix this by writing back the masked status value so that only BLF is cleared, preserving other status flags. Fixes: ffe1c5a2d427 ("rtc: abx80x: Implement RTC_VL_READ,CLR ioctls") Signed-off-by: Antoni Pokusinski Link: https://patch.msgid.link/20260415160610.127155-2-apokusinski01@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 84ac7a0f956247e5cc4b30bc84edc54d2516c976 Author: Ioana Ciornei Date: Thu Jun 18 12:28:12 2026 +0300 dpaa2-switch: do not accept VLAN uppers while bridged [ Upstream commit d07d80b6a129a44538cda1549b7acf95154fb197 ] The dpaa2-switch driver does not support VLAN uppers while its ports are bridged. This scenario tried to be prevented by rejecting a bridge join while VLAN uppers exist but the reverse order was still possible. This patches adds a check so that the dpaa2-switch also does not accept VLAN uppers while bridged. Fixes: f48298d3fbfa ("staging: dpaa2-switch: move the driver out of staging") Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260618092813.432535-2-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a3b2ee1e96d0580a8ed8deda6dfa430604f9ab0 Author: Jiayuan Chen Date: Thu Jun 18 18:43:35 2026 +0800 ipv6: ioam: fix type confusion of dst_entry [ Upstream commit 9ed19e11d2146076d117d51a940643990118449b ] IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs. Fixes: 47ce7c854563 ("net: ipv6: ioam6: fix double reallocation") Signed-off-by: Jiayuan Chen Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260618104336.48934-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63d1c23764de2309cedbb779c75188d257a09d9b Author: Weiming Shi Date: Wed Jun 17 14:55:13 2026 +0800 ipv6: ndisc: fix NULL deref in accept_untracked_na() [ Upstream commit d186e942365acece7c56d39da05dd63bf95b280a ] accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev) and dereferences idev->cnf.accept_untracked_na without a NULL check, even though its only caller ndisc_recv_na() already fetched and NULL-checked idev for the same device. Both reads of dev->ip6_ptr run in the same RCU read-side critical section, but a concurrent addrconf_ifdown() can clear dev->ip6_ptr between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown() without the synchronize_net() that orders the unregister path, so the re-fetch returns NULL and oopses: BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974) Read of size 4 at addr 0000000000000364 Call Trace: ndisc_recv_na (net/ipv6/ndisc.c:974) icmpv6_rcv (net/ipv6/icmp.c:1193) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479) ip6_input_finish (net/ipv6/ip6_input.c:534) ip6_input (net/ipv6/ip6_input.c:545) ip6_mc_input (net/ipv6/ip6_input.c:635) ipv6_rcv (net/ipv6/ip6_input.c:351) It is reachable by an unprivileged user via a network namespace. Pass the caller's already validated idev instead of re-fetching it; the idev stays alive for the whole RCU critical section, so it is safe even after dev->ip6_ptr has been cleared. Fixes: aaa5f515b16b ("net: ipv6: new accept_untracked_na option to accept na only if in-network") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260617065512.2529757-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4d7d8fdcc5976749555873aa5853cfe3e5b4ac3 Author: Wayen Yan Date: Sat Jun 20 16:17:44 2026 +0800 net: airoha: Fix skb->priority underflow in airoha_dev_select_queue() [ Upstream commit 86e51aa24686cc95bb35613059e8b94b9b81e3f0 ] In airoha_dev_select_queue(), the expression: queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES; implicitly converts to unsigned arithmetic: when skb->priority is 0 (the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX, and UINT_MAX % 8 = 7, routing default best-effort packets to the highest-priority QoS queue. This causes QoS inversion where the majority of traffic on a PON gateway starves actual high-priority flows (VoIP, gaming, etc.). The "- 1" offset was a leftover from the ETS offload implementation that has since been removed. The correct mapping is a direct modulo: queue = skb->priority % AIROHA_NUM_QOS_QUEUES; This maps priority 0 → queue 0 (lowest), priority 7 → queue 7 (highest), with higher priorities wrapping around. This is the standard Linux sk_prio → HW queue mapping used by other drivers. Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback") Link: https://lore.kernel.org/netdev/178185573207.2378135.3729126358670287878@gmail.com/ Acked-by: Lorenzo Bianconi Reviewed-by: Joe Damato Signed-off-by: Wayen Yan Link: https://patch.msgid.link/178194366700.2485734.5368768965976693502@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c3d8fc87e10e38fe054ece009d6d1f66bef2cd4 Author: Michael Bommarito Date: Wed Jun 17 17:57:08 2026 -0400 net/sched: act_ct: fix nf_connlabels leak on two error paths [ Upstream commit 16e088016f38cf728a0de709c3335cc5a3850476 ] tcf_ct_fill_params() calls nf_connlabels_get() (setting put_labels) when TCA_CT_LABELS is present, but two later error sites use a bare return instead of "goto err", skipping the err: nf_connlabels_put() cleanup. They also precede the "p->put_labels = put_labels" assignment, so the tcf_ct_params_free() fallback does not release the count either. Each failed RTM_NEWACTION on these paths leaks one nf_connlabels reference: net->ct.labels_used is incremented and never released. The action is reachable with CAP_NET_ADMIN over the netns, i.e. from an unprivileged user namespace on default-userns kernels. Impact: an unprivileged user with CAP_NET_ADMIN over a network namespace (e.g. via user namespaces) leaks one nf_connlabels reference per failed RTM_NEWACTION on the two error paths; net->ct.labels_used is never released. The err: label is safe to reach from both sites: p->tmpl is still NULL there (kzalloc'd, not yet assigned) and nf_ct_put(NULL) is a no-op, so no inline release is needed. Fixes: 70f06c115bcc ("sched: act_ct: switch to per-action label counting") Signed-off-by: Michael Bommarito Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260617215708.1115818-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 44068b6863fbda78fc810921ddf61642c377b3ca Author: Rosen Penev Date: Wed Jun 17 19:34:05 2026 -0700 net: emac: Fix NULL pointer dereference in emac_probe [ Upstream commit f623d38fe6c4e8c40b23f42cc6fe6963fa49997b ] Move devm_request_irq() after devm_platform_ioremap_resource() so that dev->emacp is mapped before the interrupt handler can fire. An early interrupt hitting emac_irq() would dereference the NULL dev->emacp and crash. Also remove redundant error message. devm_platform_ioremap_resource() already returns an error message with dev_err_probe(). Fixes: dcc34ef7c834 ("net: ibm: emac: manage emac_irq with devm") Signed-off-by: Rosen Penev Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260618023405.415644-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0ab67f7e7cfca53eb9818caabcfd747584319e9 Author: Geetha sowjanya Date: Wed Jun 17 00:30:20 2026 +0530 octeontx2-pf: mcs: Fix mcs resources free on PF shutdown [ Upstream commit 450d0e90b10393bd9f50c127875a9fdd4cc81c30 ] On PF shutdown, the current driver free mcs hardware resources though mcs resources are not allocated to it. This patch checks the mcs resources status and if resources are allocated then only sends mailbox message to free them. Fixes: c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading") Signed-off-by: Geetha sowjanya Signed-off-by: Subbaraya Sundeep Link: https://patch.msgid.link/1781636420-19816-3-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e7f1311e7ef3371e0f8e9b24ef407aff48626d9d Author: Subbaraya Sundeep Date: Wed Jun 17 00:30:19 2026 +0530 octeontx2-pf: Clear stats of all resources when freeing resources [ Upstream commit fd4460721fb4062ef470ecdfdaedadfe7e415c09 ] When all MCS resources mapped to a PF are being freed then clear stats of all those resources too. Fixes: 815debbbf7b5 ("octeontx2-pf: mcs: Clear stats before freeing resource") Signed-off-by: Subbaraya Sundeep Link: https://patch.msgid.link/1781636420-19816-2-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a56fd8449de815546c67d8fabba7611d0bf9ec5f Author: Geetha sowjanya Date: Wed Jun 17 00:30:18 2026 +0530 octeontx2-af: mcs: Fix unsupported secy stats read [ Upstream commit d4b7440f7316e76f013f57d8b6da069a1b9c34e7 ] Secy control stats counter doesn't exist for CNF10KB platform. Skip reading this respective register for CNF10KB silicon while fetching secy stats. Fixes: 9312150af8da ("octeontx2-af: cn10k: mcs: Support for stats collection") Signed-off-by: Geetha sowjanya Signed-off-by: Subbaraya Sundeep Link: https://patch.msgid.link/1781636420-19816-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e129d1a4c2bad55fd082c9c67c928ad57846461f Author: Ratheesh Kannoth Date: Wed Jun 17 15:51:49 2026 +0530 octeontx2-af: npc: cn20k: fix NPC defrag [ Upstream commit 48b67c0e8af65acd59d81ddaedd3442b5e4c27b7 ] npc_defrag_alloc_free_slots() always passed NPC_MCAM_KEY_X2 into __npc_subbank_alloc(), which must match sb->key_type, so defrag never allocated replacement slots on X4 banks. Pass the subbank key type for bank 0, and only extend the search into bank 1 for X2 (X4 MCAM indices are confined to b0b..b0t). Fixes: 645c6e3c1999 ("octeontx2-af: npc: cn20k: virtual index support") Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260617102149.1309913-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c36cecf9903f882f6d83a842ee0cb31a13ab747e Author: Wayen Yan Date: Wed Jun 17 13:48:13 2026 +0800 net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths [ Upstream commit 41782770be567abc6509169d0ffdada31c783a66 ] In mtk_ppe_init(), when accounting is enabled, the error paths for dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL directly, bypassing the err_free_l2_flows label that destroys the rhashtable initialized earlier. While this leak only occurs during probe (not runtime) and the leaked memory is minimal (an empty rhash table), fixing it ensures proper error path cleanup consistency. Fix by changing the two return NULL statements to goto err_free_l2_flows. Fixes: 603ea5e7ffa7 ("net: ethernet: mtk_eth_soc: fix memory leak in error path") Signed-off-by: Wayen Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/178167550101.2217645.14579307712717502425@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ce31739fe88a558370135db95bbeec1e7ddfc29 Author: Ilya Maximets Date: Tue Jun 16 12:03:29 2026 +0200 net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone [ Upstream commit 4c6d43db2a4d2cef3921e885cf34798f790d34ea ] kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the structure to the options_len, which is then initialized to zero. Later, we're initializing the structure by copying the tunnel info together with the options, and this triggers a warning for a potential memcpy overflow, since the compiler estimates that the options can't fit into the structure, even though the memory for them is actually allocated. memcpy: detected buffer overflow: 104 byte write of buffer size 96 WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report skb_tunnel_info_unclone+0x179/0x190 geneve_xmit+0x7fe/0xe00 The issue is triggered when built with clang and source fortification. Fix that by doing the copy in two stages: first - the main data with the options_len, then the options. This way the correct length should be known at the time of the copy. It would be better if the options_len never changed after allocation, but the allocation code is a little separate from the initialization and it would be awkward and potentially dangerous to return a struct with options_len set to a non-zero value from the metadata_dst_alloc(). Another option would be to use ip_tunnel_info_opts_set(), but it is doing too many unnecessary operations for the use case here. Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Reported-by: Johan Thomsen Closes: https://lore.kernel.org/netdev/CAKv6aAM8_EWgXScnKmKYm_4SwGDVBK++dzfP+Y6msUXbp99QUw@mail.gmail.com/ Signed-off-by: Ilya Maximets Link: https://patch.msgid.link/20260616100332.1308294-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b65289e1c3f352a9f92c6e19713ddd647e033253 Author: Weiming Shi Date: Wed Jun 17 21:57:45 2026 +0800 tipc: fix use-after-free of the discoverer in tipc_disc_rcv() [ Upstream commit 1579342d71133da7f00daa02c75cebec7372097b ] bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP. Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260617135744.3383175-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 31d486562062936af812c8892ece0a616ab9b544 Author: Ruoyu Wang Date: Thu Jun 18 03:32:28 2026 +0800 net: marvell: prestera: initialize err in prestera_port_sfp_bind [ Upstream commit 62b01f72d93c7bc8fde3b2e5b5f783eca5f53324 ] prestera_port_sfp_bind() returns err after walking the ports node. If no child node matches the port's front-panel id, err is never assigned. Initialize err to 0 because absence of a matching optional port device tree node is not an error. In that case no phylink is created and port creation should continue with port->phy_link left NULL. Errors from malformed matched nodes and phylink_create() still propagate. Fixes: 52323ef75414 ("net: marvell: prestera: add phylink support") Signed-off-by: Ruoyu Wang Reviewed-by: Maxime Chevallier Acked-by: Elad Nachman Link: https://patch.msgid.link/20260617193228.1653582-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c439591f70352a596c4e5cc414e6b001790e95c Author: Aboorva Devarajan Date: Thu Jun 11 09:11:02 2026 +0530 selftests/mm: fix exclusive_cow test fork() handling [ Upstream commit cea5702144615878600d3a39b5d8b3cc34719012 ] The test ignores the return value of fork(), so both the parent and the (newly created) child run the COW verification loops and then call hmm_buffer_free() before returning into the kselftest harness, which _exit()s each side. This duplicated teardown sequence has been observed to manifest as a SIGSEGV in the test child, e.g.: hmm-tests[360141]: segfault (11) at 0 nip 10006964 lr 1000ac3c code 1 in hmm-tests[6964,10000000+30000] Fix this by adopting the same fork()-then-wait pattern already used by the nearby anon_write_child / anon_write_child_shared tests in this file: the child performs the COW verification and then _exit(0)s so it does not run the test teardown, while the parent independently verifies COW, waits for the child, and only then frees the buffer. Link: https://lore.kernel.org/20260611034102.1030738-4-aboorvad@linux.ibm.com Fixes: b659baea75469 ("mm: selftests for exclusive device memory") Signed-off-by: Aboorva Devarajan Cc: Alex Sierra Cc: Alistair Popple Cc: Balbir Singh Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Ralph Campbell Cc: Sayali Patil Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 214ba45968877f3b61f49ebf6fe2691895385aca Author: Sayali Patil Date: Thu Jun 11 09:11:01 2026 +0530 selftests/mm: remove hardcoded THP sizing assumptions in hmm tests [ Upstream commit 8edb0e769ce2a996774df83485781dd9f4bc2d44 ] migrate_partial_unmap_fault() and migrate_remap_fault() use hardcoded offsets based on a 2MB PMD size. Similarly, benchmark_thp_migration() assumes a fixed 2MB THP size when generating test buffer sizes. Derive offsets and test sizes from the runtime PMD page size returned by read_pmd_pagesize(). If unavailable, fall back to TWOMEG. This allows the tests to adapt correctly on systems where PMD-sized THP differs from 2MB. Also replace the fixed 1MB unmap size with a PMD-relative value derived from the runtime PMD size. On systems with larger PMD sizes, computed test buffer sizes can exceed INT_MAX. Skip such test cases to avoid overflow. Link: https://lore.kernel.org/20260611034102.1030738-3-aboorvad@linux.ibm.com Fixes: 24c2c5b8ffbd ("selftests/mm/hmm-tests: partial unmap, mremap and anon_write tests") Fixes: 271a7b2e3c13 ("selftests/mm/hmm-tests: new throughput tests including THP") Signed-off-by: Sayali Patil Signed-off-by: Aboorva Devarajan Acked-by: Balbir Singh Cc: Alex Sierra Cc: Alistair Popple Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Ralph Campbell Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 679642fa56d524dc86253ce3761872df49be355c Author: Sayali Patil Date: Thu Jun 11 09:11:00 2026 +0530 selftests/mm: allow PUD-level entries in compound testcase of hmm tests [ Upstream commit 224ed0e019b122d08580362abe57574a78f2b5fa ] Patch series "selftests/mm: assorted fixes for hmm-tests", v3. This series fixes a few issues in hmm-tests that show up when page-size and huge-page configuration differ from the hardcoded assumptions the tests were written for (PMD/THP sizing, default hugepage size, and related cases). It also includes a fix to exclusive_cow: the test ignored the return value of fork(), so both parent and child ran the same teardown path. This patch (of 3): The HMM compound testcase currently assumes only PMD-level mappings and fails on systems where default_hugepagesz=1G is set, because the region is then reported by the device at PUD level. Determine the mapping level (PMD or PUD) the device reports for the first page of the range and require every page to match that level exactly via ASSERT_EQ(). This accepts PUD-level mappings while preserving the expected/observed protection values printed on failure, and rejects a fragmented mapping that mixes PMD- and PUD-level entries within the same range (which a per-page OR check would have let pass). Link: https://lore.kernel.org/20260611034102.1030738-1-aboorvad@linux.ibm.com Link: https://lore.kernel.org/20260611034102.1030738-2-aboorvad@linux.ibm.com Fixes: e478425bec93 ("mm/hmm: add tests for hmm_pfn_to_map_order()") Signed-off-by: Sayali Patil Co-developed-by: Aboorva Devarajan Signed-off-by: Aboorva Devarajan Cc: Alex Sierra Cc: Alistair Popple Cc: Balbir Singh Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Ralph Campbell Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0481f4bad161f46e4e6490f457297aa04e4787e6 Author: Sayali Patil Date: Thu May 21 12:17:53 2026 +0530 selftests/mm: clarify alternate unmapping in compaction_test [ Upstream commit 69ba1d76d93ab818245333cf400928477ba72053 ] Add a comment explaining that every other entry in the list is unmapped to intentionally create fragmentation with locked pages before invoking check_compaction(). Link: https://lore.kernel.org/da5e0a8d5152e54152c0d2f456aac2fac35af291.1779296493.git.sayalip@linux.ibm.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Sayali Patil Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2a018e29ac5ff55806cce76cdb5e2e76c021e537 Author: Sayali Patil Date: Thu May 21 12:17:52 2026 +0530 selftests/mm: move hwpoison setup into run_test() and silence modprobe output for memory-failure category [ Upstream commit 90c132f8379b788a0482dbeabc884d3ae5d82205 ] run_vmtests.sh contains special handling to ensure the hwpoison_inject module is available for the memory-failure tests. This logic was implemented outside of run_test(), making the setup category-specific but managed globally. Move the hwpoison_inject handling into run_test() and restrict it to the memory-failure category so that: 1. the module is checked and loaded only when memory-failure tests run, 2. the test is skipped if the module or the debugfs interface (/sys/kernel/debug/hwpoison/) is not available. 3. the module is unloaded after the test if it was loaded by the script. This localizes category-specific setup and makes the test flow consistent with other per-category preparations. While updating this logic, fix the module availability check. The script previously used: modprobe -R hwpoison_inject The -R option prints the resolved module name to stdout, causing every run to print: hwpoison_inject in the test output, even when no action is required, introducing unnecessary noise. Replace this with: modprobe -n hwpoison_inject which verifies that the module is loadable without producing output, keeping the selftest logs clean and consistent. Also, ensure that skipped tests do not override a previously recorded failure. A skipped test currently sets exitcode to ksft_skip even if a prior test has failed, which can mask failures in the final exit status. Update the logic to only set exitcode to ksft_skip when no failure has been recorded. Link: https://lore.kernel.org/93441f34f7ef5add47d1a130d03daa79e21b5050.1779296493.git.sayalip@linux.ibm.com Fixes: ff4ef2fbd101 ("selftests/mm: add memory failure anonymous page test") Signed-off-by: Sayali Patil Reviewed-by: Miaohe Lin Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 835ef922f3baba7500c3cf51790d9c75643b48b9 Author: Mike Rapoport (Microsoft) Date: Mon May 11 19:28:38 2026 +0300 selftests/mm: run_vmtests.sh: free memory if available memory is low [ Upstream commit 157adc22f01cdd0c0dc1b9e4389ed2377d9b69d3 ] Currently when running THP and HugeTLB tests, if HAVE_HUGEPAGES is set run_test() drops caches, compacts memory and runs the test. But if HAVE_HUGEPAGES is not set it skips the tests entirely, even if THP tests have nothing to do with HAVE_HUGEPAGES. Replace the check if HAVE_HUGEPAGES is set with a check of how much memory is available. If there is less than 256 MB of available memory, drop caches and run compaction and then continue to run a test regardless of HAVE_HUGEPAGES value. Link: https://lore.kernel.org/20260511162840.375890-55-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Tested-by: Luiz Capitulino Tested-by: Sarthak Sharma Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Donet Tom Cc: Jason Gunthorpe Cc: John Hubbard Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Li Wang Cc: Lorenzo Stoakes Cc: Mark Brown Cc: Michal Hocko Cc: Nico Pache Cc: Peter Xu Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: 90c132f8379b ("selftests/mm: move hwpoison setup into run_test() and silence modprobe output for memory-failure category") Signed-off-by: Sasha Levin commit de72caed5077aabe63dcf88b7ea45cac2d804fbc Author: Sayali Patil Date: Thu May 21 12:17:51 2026 +0530 selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero [ Upstream commit f3bd00507f226a419125df6064632bcbd47d8e70 ] uffd-stress currently fails when the computed nr_pages_per_cpu evaluates to zero: nr_pages_per_cpu = bytes / page_size / nr_parallel This can occur on systems with large hugepage sizes (e.g. 1GB) and a high number of CPUs, where the total allocated memory is sufficient overall but not enough to provide at least one page per cpu. In such cases, the failure is due to insufficient test resources rather than incorrect kernel behaviour. Update the test to treat this condition as a test skip instead of reporting an error. [sayalip@linux.ibm.com: use ksft_exit_skip() instead of KSFT_SKIP] Link: https://lore.kernel.org/88202b56-1dc5-43e2-9d1f-a0823a9531f0@linux.ibm.com Link: https://lore.kernel.org/0707e9a0f1b3dd904c4a069b91db317f9c160faa.1779296493.git.sayalip@linux.ibm.com Fixes: db0f1c138f18 ("selftests/mm: print some details when uffd-stress gets bad params") Signed-off-by: Sayali Patil Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e186a9ac7af40419f1dad33c0c0c80de790f321e Author: Sayali Patil Date: Thu May 21 12:17:49 2026 +0530 selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap [ Upstream commit f20ca8972e83f111c4300c60d74314568c8964bc ] The hugetlb-mremap selftest reserves the destination address using a anonymous base-page mapping before calling mremap() with MREMAP_FIXED, while the source region is hugetlb-backed. When remapping a hugetlb mapping into a base-page VMA may fail with: mremap: Device or resource busy This is observed on powerpc hash MMU systems where slice constraints and page size incompatibilities prevent the remap. Ensure the destination region is created using MAP_HUGETLB so that both source and destination VMAs are hugetlb-backed and compatible. Update the FLAGS macro to include MAP_HUGETLB | MAP_SHARED so that both mappings are hugetlb-backed and compatible. Also use the macro for the mmap() calls to avoid repeating the flag combination. This ensures the test reliably exercises hugetlb mremap instead of failing due to VMA type mismatch. Link: https://lore.kernel.org/367644df45c65098f23e3945c6a80f4b8a8964a6.1779296493.git.sayalip@linux.ibm.com Fixes: 12b613206474 ("mm, hugepages: add hugetlb vma mremap() test") Signed-off-by: Sayali Patil Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e0f39f7671a9fd43ae2a9c4ea9cbd7e229ccf2c3 Author: Sayali Patil Date: Thu May 21 12:17:48 2026 +0530 selftest/mm: register existing mapping with userfaultfd in hugetlb-mremap [ Upstream commit 1df31d5ef58dc6bdf0f2a8b809152d835c60b28e ] Previously, register_region_with_uffd() created a new anonymous mapping and overwrote the address supplied by the caller before registering the range with userfaultfd. As a result, userfaultfd was applied to an unrelated anonymous mapping instead of the hugetlb region used by the test. Remove the extra mmap() and register the caller-provided address range directly using UFFDIO_REGISTER_MODE_MISSING, so that faults are generated for the hugetlb mapping used by the test. This ensures userfaultfd operates on the actual hugetlb test region and validates the expected fault handling. Before patch: running ./hugetlb-mremap ------------------------- TAP version 13 1..1 Map haddr: Returned address is 0x7eaa40000000 Map daddr: Returned address is 0x7daa40000000 Map vaddr: Returned address is 0x7faa40000000 Address returned by mmap() = 0x7fff9d000000 Mremap: Returned address is 0x7faa40000000 First hex is 0 First hex is 3020100 ok 1 Read same data Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 hugetlb-mremap After patch: running ./hugetb-mremap ------------------------- TAP version 13 1..1 Map haddr: Returned address is 0x7eaa40000000 Map daddr: Returned address is 0x7daa40000000 Map vaddr: Returned address is 0x7faa40000000 Registered memory at address 0x7eaa40000000 with userfaultfd Mremap: Returned address is 0x7faa40000000 First hex is 0 First hex is 3020100 ok 1 Read same data Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 hugetlb-mremap Link: https://lore.kernel.org/13845da872ed174316173e8996dbb5f181994017.1779296493.git.sayalip@linux.ibm.com Fixes: 12b613206474 ("mm, hugepages: add hugetlb vma mremap() test") Signed-off-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7c0ba2376d40fa729b915eb628847e61bfa9e3b3 Author: Sayali Patil Date: Thu May 21 12:17:47 2026 +0530 selftests/mm: free dynamically allocated PMD-sized buffers in split_huge_page_test [ Upstream commit e5d3e1422e92d54e28e81fad8bfc7c1ecb41a353 ] Dynamically allocated buffers of PMD size for file-backed THP operations (file_buf1 and file_buf2) were not freed on the success path and some failure paths. Since the function is called repeatedly in a loop for each split order, this can cause significant memory leaks. On architectures with large PMD sizes, repeated leaks could exhaust system memory and trigger the OOM killer during test execution. Ensure all allocated buffers are freed to maintain stable repeated test runs. Link: https://lore.kernel.org/060c673b376bbeeed2b1fb1d48a825e846654191.1779296493.git.sayalip@linux.ibm.com Fixes: 035a112e5fd5 ("selftests/mm: make file-backed THP split work by writing PMD size data") Signed-off-by: Sayali Patil Reviewed-by: Zi Yan Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5b136718617aab1b494dc199edf84305230100ed Author: Sayali Patil Date: Thu May 21 12:17:46 2026 +0530 selftests/mm: size tmpfs according to PMD page size in split_huge_page_test [ Upstream commit a2dde8a065d5c8d63b53b1c8f035017e4aeac0c2 ] The split_file_backed_thp() test mounts a tmpfs with a fixed size of "4m". This works on systems with smaller PMD page sizes, but fails on configurations where the PMD huge page size is larger (e.g. 16MB). On such systems, the fixed 4MB tmpfs is insufficient to allocate even a single PMD-sized THP, causing the test to fail. Fix this by sizing the tmpfs dynamically based on the runtime pmd_pagesize, allocating space for two PMD-sized pages. Before patch: running ./split_huge_page_test /tmp/xfs_dir_YTrI5E -------------------------------------------------- TAP version 13 1..55 ok 1 Split zero filled huge pages successful ok 2 Split huge pages to order 0 successful ok 3 Split huge pages to order 2 successful ok 4 Split huge pages to order 3 successful ok 5 Split huge pages to order 4 successful ok 6 Split huge pages to order 5 successful ok 7 Split huge pages to order 6 successful ok 8 Split huge pages to order 7 successful ok 9 Split PTE-mapped huge pages successful Please enable pr_debug in split_huge_pages_in_file() for more info. Failed to write data to testing file: Success (0) Bail out! Error occurred Planned tests != run tests (55 != 9) Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0 [FAIL] After patch: running ./split_huge_page_test /tmp/xfs_dir_bMvj6o -------------------------------------------------- TAP version 13 1..55 ok 1 Split zero filled huge pages successful ok 2 Split huge pages to order 0 successful ok 3 Split huge pages to order 2 successful ok 4 Split huge pages to order 3 successful ok 5 Split huge pages to order 4 successful ok 6 Split huge pages to order 5 successful ok 7 Split huge pages to order 6 successful ok 8 Split huge pages to order 7 successful ok 9 Split PTE-mapped huge pages successful Please enable pr_debug in split_huge_pages_in_file() for more info. Please check dmesg for more information ok 10 File-backed THP split to order 0 test done Please enable pr_debug in split_huge_pages_in_file() for more info. Please check dmesg for more information ok 11 File-backed THP split to order 1 test done Please enable pr_debug in split_huge_pages_in_file() for more info. Please check dmesg for more information ok 12 File-backed THP split to order 2 test done ... ok 55 Split PMD-mapped pagecache folio to order 7 at in-folio offset 128 passed Totals: pass:55 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 split_huge_page_test /tmp/xfs_dir_bMvj6o Link: https://lore.kernel.org/33e1bc10753fe82d1217613d8cd496020778cf2b.1779296493.git.sayalip@linux.ibm.com Fixes: fbe37501b252 ("mm: huge_memory: debugfs for file-backed THP split") Signed-off-by: Sayali Patil Reviewed-by: Zi Yan Reviewed-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit aef0f2059a97174be1cb50801331fa12580420af Author: Sayali Patil Date: Thu May 21 12:17:45 2026 +0530 selftests/mm: fix cgroup task placement and drop memory.current checks in hugetlb_reparenting_test.sh [ Upstream commit 7bbdc459527075c4d0b96133de25a53822397af0 ] The test currently moves the calling shell ($$) into the target cgroup before executing write_to_hugetlbfs. This results in the shell and any intermediate allocations being charged to the cgroup, introducing noise and nondeterminism in accounting. It also requires moving the shell back to the root cgroup after execution. Spawn a helper process that joins the target cgroup and exec()'s write_to_hugetlbfs. This ensures that only the workload is accounted to the cgroup and avoids unintended charging from the shell. The test currently validates both hugetlb usage and memory.current. However, memory.current includes internal memcg allocations and per-CPU batched accounting (MEMCG_CHARGE_BATCH), which are not synchronized and can vary across systems, leading to non-deterministic results. Since hugetlb memory is accounted via hugetlb..current, memory.current is not a reliable indicator here. Drop memory.current checks and rely only on hugetlb controller statistics for stable and accurate validation. Link: https://lore.kernel.org/fb57491ba83cb0a499c72922e1579b61bee514db.1779296493.git.sayalip@linux.ibm.com Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Sayali Patil Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Venkat Rao Bagalkote Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4a1e9beaff98bbb826f8891aee10c9081709c187 Author: Sayali Patil Date: Thu May 21 12:17:44 2026 +0530 selftests/mm: fix hugetlb pathname construction in hugetlb_reparenting_test.sh [ Upstream commit 76f9a212a0a93572a28b58d9869e9187c4022342 ] The hugetlb_reparenting_test.sh script constructs hugetlb cgroup memory interface file names based on the configured huge page size. The script formats the size only in MB units, which causes mismatches on systems using larger huge pages where the kernel exposes normalized units (e.g. "1GB" instead of "1024MB"). As a result, the test fails to locate the corresponding cgroup files when 1GB huge pages are configured. Update the script to detect the huge page size and select the appropriate unit (MB or GB) so that the constructed paths match the kernel's hugetlb controller naming. Also print an explicit "Fail" message when a test failure occurs to improve result visibility. Link: https://lore.kernel.org/837ce751965c93f74c95d89587debf1e93281364.1779296493.git.sayalip@linux.ibm.com Fixes: e487a5d513cb ("selftest/mm: make hugetlb_reparenting_test tolerant to async reparenting") Signed-off-by: Sayali Patil Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 95f64f30431edfeb22ceeba4c33e27784f28861d Author: Sayali Patil Date: Thu May 21 12:17:43 2026 +0530 selftests/mm: restore default nr_hugepages value via exit trap in hugetlb_reparenting_test.sh [ Upstream commit 7f9c0920ff3debae3cb4d60260e3daf56ab68395 ] The test modifies nr_hugepages during execution and restores it from cleanup() and again reconfigure it setup, which is invoked multiple times across test flow. This can lead to repeated allocation/freeing of hugepages. With set -e, failures in cleanup (e.g., rmdir/umount) can also cause early exit before restoring the original value at the end. Move restoration of the original nr_hugepages value to a trap handler registered for EXIT, INT, and TERM signals so it is always restored on all exit paths. This also avoids unnecessary allocation churn across repeated cleanup/setup cycles. Link: https://lore.kernel.org/29db637c3c6ba6c168f6b33f59f059a0b39c35c8.1779296493.git.sayalip@linux.ibm.com Fixes: 585a9145886a ("selftests/mm: restore default nr_hugepages value during cleanup in hugetlb_reparenting_test.sh") Signed-off-by: Sayali Patil Acked-by: Zi Yan Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 65a7bc39d4a209c39495b91b7ffb2357c77495fa Author: Sayali Patil Date: Thu May 21 12:03:28 2026 +0530 selftests/mm: fix hugetlb pathname construction in charge_reserved_hugetlb.sh [ Upstream commit 404c04e010da2edc93cada07d4d50deda12a68e4 ] The charge_reserved_hugetlb.sh script assumes hugetlb cgroup memory interface file names use the "MB" format (e.g. hugetlb.1024MB.current). This assumption breaks on systems with larger huge pages such as 1GB, where the kernel exposes normalized units: hugetlb.1GB.current hugetlb.1GB.max hugetlb.1GB.rsvd.max ... As a result, the script attempts to access files like hugetlb.1024MB.current, which do not exist when the kernel reports the size in GB. Normalize the huge page size and construct the pathname using the appropriate unit (MB or GB), matching the hugetlb controller naming. Link: https://lore.kernel.org/04b6b49e4a2acf46319f627caf82b09e6dc1ad7f.1779296493.git.sayalip@linux.ibm.com Fixes: 209376ed2a84 ("selftests/vm: make charge_reserved_hugetlb.sh work with existing cgroup setting") Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Sayali Patil Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 83d9d5f63cc974d2e7449a3974df7f809cb6260b Author: Sayali Patil Date: Thu May 21 12:03:27 2026 +0530 selftests/mm: restore default nr_hugepages value via exit trap in charge_reserved_hugetlb.sh [ Upstream commit a3f66e9b6e4dad38444656ffc28c28c33a4d4e1f ] Patch series "selftests/mm: fix failures and robustness improvements", v7. Powerpc systems with a 64K base page size exposed several issues while running mm selftests. Some tests assume specific hugetlb configurations, use incorrect interfaces, or fail instead of skipping when the required kernel features are not available. This series fixes these issues and improves test robustness. This patch (of 13): cleanup() resets nr_hugepages to 0 on every invocation, while the test reconfigures it again in the next iteration. This leads to repeated allocation and freeing of large numbers of hugepages, especially when the original value is high. Additionally, with set -e, failures in earlier cleanup steps (e.g., rmdir or umount returning EBUSY while background activity is still ongoing) can cause the script to exit before restoring the original value, leaving the system in a modified state. Introduce a trap on EXIT, INT, and TERM to restore the original nr_hugepages value once at script termination. This avoids unnecessary allocation churn and ensures the original value is reliably restored on all exit paths. Link: https://lore.kernel.org/cover.1779296493.git.sayalip@linux.ibm.com Link: https://lore.kernel.org/5b8fbb29cd6ceffe6752e0af104f60cec072aa10.1779296493.git.sayalip@linux.ibm.com Fixes: 7d695b1c3695 ("selftests/mm: save and restore nr_hugepages value") Signed-off-by: Sayali Patil Acked-by: Zi Yan Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 008ceffd44040f809aead6d7bef7cb1210c4149a Author: Hao Ge Date: Thu Jun 4 14:59:38 2026 +0800 alloc_tag: fix use-after-free in /proc/allocinfo after module unload [ Upstream commit 2956268efc457cb05d29c1bf94de1e8e684d7bbc ] allocinfo_start() only reinitializes the codetag iterator at position 0. For subsequent reads (position > 0), it reuses cached iterator state from the previous batch. allocinfo_stop() drops mod_lock between read batches, which allows module unload to complete and free the module memory that the cached iterator still references: CPU0 (read) CPU1 (rmmod) ---- ---- allocinfo_start(pos=0) down_read(mod_lock) allocinfo_show() ... allocinfo_stop() up_read(mod_lock) codetag_unload_module() kfree(cmod) release_module_tags() ... free_mod_mem() allocinfo_start(pos=N) down_read(mod_lock) // reuses cached iter, skips re-init allocinfo_show() ct->filename <-- UAF After free_mod_mem() frees the module's .rodata, allocinfo_show() dereferences ct->filename, ct->function which point there. Save the iterator state in allocinfo_next() and resume from it in allocinfo_start() with codetag_next_ct(), which detects module removal via idr_find() returning NULL and skips to the next module. Link: https://lore.kernel.org/20260604065938.105991-1-hao.ge@linux.dev Fixes: 9f44df50fee4 ("alloc_tag: keep codetag iterator active between read()") Signed-off-by: Hao Ge Suggested-by: Suren Baghdasaryan Acked-by: Suren Baghdasaryan Cc: Kent Overstreet Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8107796231041e08677c74eb4bb46d82688c0f3f Author: Bhargav Joshi Date: Sat Jun 20 17:39:17 2026 +0530 irqchip/crossbar: Fix parent domain resource leak [ Upstream commit a1074dd62faa6572921d387e8a21589ccea00efc ] irq_domain_alloc_irqs_parent() is called in allocate_gic_irq() but irq_domain_free_irqs_parent() is never called which causes a resource leak. Fix this by calling irq_domain_free_irqs_parent() in crossbar_domain_free(). Fixes: 783d31863fb82 ("irqchip: crossbar: Convert dra7 crossbar to stacked domains") Signed-off-by: Bhargav Joshi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260620-irq-crossbar-fix-v2-2-b8e8499f468a@gmail.com Signed-off-by: Sasha Levin commit 74b19383580d63dea43644a851fefb203691a9c4 Author: Sebastian Andrzej Siewior Date: Wed Jun 17 08:55:26 2026 +0200 mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx() [ Upstream commit 82ef9a635d7130ca27ec9dd88c16afc39c83a4e8 ] imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register which may timeout and is recognized as an error. This error is siltently dropped and not dropped to the caller. Forward the error to the caller. Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit c041d2be785feb9b5e36331921eadaefbe65349d Author: Rafael J. Wysocki Date: Tue May 12 18:16:23 2026 +0200 tpm_crb: Check ACPI_COMPANION() against NULL during probe [ Upstream commit ddd33806b8911fa2ef849e8bbbab1e3fcb26adc0 ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the tpm_crb driver. Fixes: 48fe2cddc85c ("tpm_crb: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/2848144.mvXUDI8C0e@rafael.j.wysocki Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 4dce8bf588a89bef99b446136d15685a837e7acf Author: Florian Westphal Date: Fri Jun 19 00:34:49 2026 +0200 netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak [ Upstream commit 27dd2997746d54ebc079bb13161cc1bdd401d4a6 ] This needs to test for nonzero retval. Fixes: c54c7c685494 ("netfilter: nft_meta_bridge: add NFT_META_BRI_IIFPVID support") Closes: https://sashiko.dev/#/patchset/20260618061631.21919-1-fw%40strlen.de Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a259780ddf1d98372c531ab0cc38e80565c34666 Author: Florian Westphal Date: Thu Jun 18 10:49:24 2026 +0200 netfilter: nf_reject: skip iphdr options when looking for icmp header [ Upstream commit af8d6ae09c0a5f8b8a0d5680203c74b3c1daa85b ] Not a big deal but this hould have used the real ip header length and not the base header size. As-is, if there are options then nf_skb_is_icmp_unreach() result will be random. Fixes: db99b2f2b3e2 ("netfilter: nf_reject: don't reply to icmp error messages") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a75f7745dc8fe8b4120eac64cc8bc6305c0df968 Author: Florian Westphal Date: Thu Jun 18 08:25:47 2026 +0200 netfilter: nft_flow_offload: zero device address for non-ether case [ Upstream commit e409c23c2d0630f3b95efd12428b2e58800b7645 ] LLM points out that the skip causes unitialised stack array to propagate down into dev_fill_forward_path(). Its not clear to me that there is a guarantee that a later ctx.dev->netdev_ops->ndo_fill_forward_path() would always fix this up. Cc: Felix Fietkau Fixes: 45ca3e61999e ("netfilter: nft_flow_offload: skip dst neigh lookup for ppp devices") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c3167c9c6433a3586290571d327203cb9a4ca2a3 Author: Florian Westphal Date: Thu Jun 18 08:16:18 2026 +0200 netfilter: nft_meta_bridge: add validate callback for get operations [ Upstream commit bff1c8b49a9cb5c04af20f4e7d43bf4af5863bc6 ] Blamed commit added NFT_META_BRI_IIFHWADDR to the set validate callback, yet this is a get operation. Add a get validate callback and move the NFT_META_BRI_IIFHWADDR key there. AFAICS this is harmless, NFT_META_BRI_IIFHWADDR can deal with a NULL input device and the set handler ignores a NFT_META_BRI_IIFHWADDR operation, but it allows to read 4 bytes off bridge skb->cb[]. Fixes: cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support") Signed-off-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 94daa48ea7b6af36839a4d425e0cf201aea24176 Author: Florian Westphal Date: Thu Jun 18 06:58:24 2026 +0200 netfilter: nft_payload: reject offsets exceeding 65535 bytes [ Upstream commit 213be32f46a29ca15a314df06c3424ecffd6c90a ] Large offsets were rejected based on netlink policy, but blamed commit removed the policy without updating nft_payload_inner_init() to use the truncation-check helper. Silent truncation is not a problem, but not wanted either, so add a check. Fixes: 077dc4a27579 ("netfilter: nft_payload: extend offset to 65535 bytes") Signed-off-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c78bd5195a5998094a5866df702fbeafda60dafb Author: Jozsef Kadlecsik Date: Wed Jun 17 10:41:26 2026 +0200 netfilter: ipset: make sure gc is properly stopped [ Upstream commit 4a597a87e2e2f608edb6be2c510dc826b4fdfb53 ] Sashiko noticed that when destroying a set, cancel_delayed_work_sync() was called while gc calls queue_delayed_work() unconditionally which can lead not to properly shutting down the gc. Fixes: f66ee0410b1c ("netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports") Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 93a775fd67f3ef34949a9523bfa69403ee74efdd Author: Jozsef Kadlecsik Date: Wed Jun 17 10:41:24 2026 +0200 netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() [ Upstream commit 3ca9982a8882470aa0ac4e8bb9a552b181d1efcd ] Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first. Fixes: b57b2d1fa53f ("netfilter: ipset: Prepare the ipset core to use RCU at set level") Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7efd8a1c96c73c29fd77431c88673eb49b0696ac Author: Jozsef Kadlecsik Date: Wed Jun 17 10:41:23 2026 +0200 netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap types [ Upstream commit 1171192ac9af46ddf65caf4162f1b64c58ae37f4 ] The pair of the patch "netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types" for the bitmap types. Fixes: 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation") Fixes: b0da3905bb1e ("netfilter: ipset: Bitmap types using the unified code base") Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3219d74e4536658c937fd878a327257b86ce80dd Author: Jozsef Kadlecsik Date: Wed Jun 17 10:41:22 2026 +0200 netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types [ Upstream commit e4b4984e28c16406ecb318444dea4a8bf47def3e ] Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase Fixes: 18f84d41d34f ("netfilter: ipset: Introduce RCU locking in hash:* types") Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c6e6354295845698d2fdfa20b71fc404786f7e93 Author: Abd-Alrhman Masalkhi Date: Thu Jun 11 10:13:50 2026 +0000 md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on retry [ Upstream commit 69ad6ce47f9bf2b9fe0ed69b042db993d33bbf12 ] When a read is retried, raid1_read_request() may be called with a pre-allocated r1_bio. If wait_read_barrier() fails for a REQ_NOWAIT read, the bio is completed and the function returns immediately. In this case the existing r1_bio is leaked. This fixes a leak of pre-allocated r1_bio structures for retried reads. Fixes: 5aa705039c4f ("md: raid1 add nowait support") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260611083514.754922-1-abd.masalkhi@gmail.com?part=1 Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260611101350.759154-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 937c3e44ecaf5425c892256007dbfc1f78748d1f Author: Abd-Alrhman Masalkhi Date: Thu Jun 11 08:35:14 2026 +0000 md/raid1: honor REQ_NOWAIT when waiting for behind writes [ Upstream commit a286cb88ddb26c5f4377859d8e77233d9181eb82 ] raid1 supports REQ_NOWAIT reads by avoiding waits in the barrier path through wait_read_barrier(). However, a read can still block on a WriteMostly device when the array uses a bitmap and there are outstanding behind writes. In that case raid1 unconditionally calls wait_behind_writes(), which may sleep until all behind writes complete. As a result, a REQ_NOWAIT read can block despite the caller explicitly requesting non-blocking behavior. This ensures that raid1 consistently honors REQ_NOWAIT reads across all paths that may otherwise wait for behind writes. Fixes: 5aa705039c4f ("md: raid1 add nowait support") Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260611083514.754922-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit d1324b41dabd26787559efaeb430643c627c1eb0 Author: Abd-Alrhman Masalkhi Date: Sat Jun 13 18:28:09 2026 +0000 md/raid10: fix writes_pending and barrier reference leaks on discard failures [ Upstream commit 393d687131d8aa8c7e4de2cb494438e145d20fc2 ] raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped. Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced. Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference. Release the barrier before returning from those paths. Fixes: c9aa889b035f ("md: raid10 add nowait support") Fixes: 4cf58d952909 ("md/raid10: Handle bio_split() errors") Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260613182810.1317258-4-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit f94031c94eaebe14a7c9e91720064de0c5a54a6c Author: Abd-Alrhman Masalkhi Date: Sat Jun 13 18:28:08 2026 +0000 md/raid10: fix writes_pending leak on write request failures [ Upstream commit e045d6ed33f8faa3e3dd6dc33c62ec01e3ad275d ] raid10_make_request() acquires a writes_pending reference with md_write_start() before dispatching write requests. Several failure paths in raid10_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid10_write_request() return a status indicating whether the write request was successfully queued. This allows raid10_make_request() to release the writes_pending reference with md_write_end() when a write request fails. Fixes: 4cf58d952909 ("md/raid10: Handle bio_split() errors") Fixes: c9aa889b035f ("md: raid10 add nowait support") Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260613182810.1317258-3-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bffbbfcbd9393e315a7a4286dcd70e875265db9a Author: Abd-Alrhman Masalkhi Date: Sat Jun 13 18:28:07 2026 +0000 md/raid1: fix writes_pending and barrier reference leaks on write failures [ Upstream commit 8e065a1602511282fc0da2dc89445e0eb71a681c ] raid1_make_request() acquires a writes_pending reference with md_write_start() before calling raid1_write_request(). Several failure paths in raid1_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid1_write_request() return a status indicating whether the write request was successfully queued. This allows raid1_make_request() to call md_write_end() when raid1_write_request() fails. Additionally, if wait_blocked_rdev() fails after wait_barrier() succeeds, the associated barrier reference is not released. Call allow_barrier() before returning from that path to keep the barrier accounting balanced. Fixes: b1a7ad8b5c4f ("md/raid1: Handle bio_split() errors") Fixes: f2a38abf5f1c ("md/raid1: Atomic write support") Fixes: 5aa705039c4f ("md: raid1 add nowait support") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260611083514.754922-1-abd.masalkhi@gmail.com?part=1 Closes: https://sashiko.dev/#/patchset/20260611132500.763528-1-abd.masalkhi@gmail.com?part=1 Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260613182810.1317258-2-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 4fe0635fe6042ec79899e7ae3202370f1a5ca999 Author: Robertus Diawan Chris Date: Tue Jun 2 12:41:33 2026 +0700 mac802154: Prevent overwrite return code in mac802154_perform_association() [ Upstream commit 649147cb3f8b3c0c9aeba5d89d69a6ef221c12c2 ] When assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL, the return value assigned to either "-ERANGE" or "-EPERM" but this return value will be overwritten to 0 after exiting the conditional scope. So, jump to clear_assoc label to preserve the return value when assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL. This is reported by Coverity Scan as "Unused value". Fixes: fefd19807fe9 ("mac802154: Handle associating") Signed-off-by: Robertus Diawan Chris Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/20260602054133.470293-1-robertusdchris@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit f14802465f5956baafe5f4b4541eb626b06b41f1 Author: Aleksandr Nogikh Date: Wed May 27 20:18:18 2026 +0000 ieee802154: fix kernel-infoleak in dgram_recvmsg() [ Upstream commit 4db86f8ab11b5a41bfc36680be837e6ac1375ec6 ] KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`. Fixes: 94b4f6c21cf5 ("ieee802154: add header structs with endiannes and operations") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+346474e3bf0b26bd3090@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=346474e3bf0b26bd3090 Link: https://syzkaller.appspot.com/ai_job?id=a507a109-d683-4a2c-bc03-93394f491b17 Signed-off-by: Aleksandr Nogikh Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/62795fd9-fc0c-48eb-bb82-05ffc5a57104@mail.kernel.org Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 4c3717546878c5f271943c574d1dc1fb6fd51b8f Author: Ivan Abramov Date: Thu Apr 3 13:19:34 2025 +0300 ieee802154: Remove WARN_ON() in cfg802154_pernet_exit() [ Upstream commit e69ed6fc9fb3b386b5fcdb9f51623f122cee2ebd ] There's no need to call WARN_ON() in cfg802154_pernet_exit(), since every point of failure in cfg802154_switch_netns() is covered with WARN_ON(), so remove it. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 66e5c2672cd1 ("ieee802154: add netns support") Reviewed-by: Miquel Raynal Signed-off-by: Ivan Abramov Link: https://lore.kernel.org/20250403101935.991385-4-i.abramov@mt-integration.ru Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 6fcba77571c53f656a2f109259601a7570d4c74a Author: Ivan Abramov Date: Thu Apr 3 13:19:33 2025 +0300 ieee802154: Avoid calling WARN_ON() on -ENOMEM in cfg802154_switch_netns() [ Upstream commit 0569f67ed6a7af838e2141da93c68e6b6013f483 ] It's pointless to call WARN_ON() in case of an allocation failure in dev_change_net_namespace() and device_rename(), since it only leads to useless splats caused by deliberate fault injections, so avoid it. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 66e5c2672cd1 ("ieee802154: add netns support") Reported-by: syzbot+e0bd4e4815a910c0daa8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/000000000000f4a1b7061f9421de@google.com/#t Reviewed-by: Kuniyuki Iwashima Reviewed-by: Miquel Raynal Signed-off-by: Ivan Abramov Link: https://lore.kernel.org/20250403101935.991385-3-i.abramov@mt-integration.ru Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 8a4eae78287a4074e70fdb38932929eaf1f55115 Author: Ivan Abramov Date: Thu Apr 3 13:19:32 2025 +0300 ieee802154: Restore initial state on failed device_rename() in cfg802154_switch_netns() [ Upstream commit a2e06b4bef20b59446d5088e938c2be53cc4e6c6 ] Currently, the return value of device_rename() is not acted upon. To avoid an inconsistent state in case of failure, roll back the changes made before the device_rename() call. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 66e5c2672cd1 ("ieee802154: add netns support") Reviewed-by: Miquel Raynal Signed-off-by: Ivan Abramov Link: https://lore.kernel.org/20250403101935.991385-2-i.abramov@mt-integration.ru Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 315e1efc3f16b64c9b6c30bcc44fd622cfc7195f Author: Xu Rao Date: Tue Jun 16 17:36:21 2026 +0800 ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone() [ Upstream commit 71b57aca295d61276a60e131d8f62b0cc7cf1a35 ] Before commit a1a69b297e47 ("ACPI / IPMI: Fix race caused by the unprotected ACPI IPMI user"), ipmi_bmc_gone() skipped entries whose interface number did not match the SMI being removed, then killed the matching entry: if (ipmi_device->ipmi_ifnum != iface) continue; __ipmi_dev_kill(ipmi_device); That commit folded the removal block into the existing non-match test while converting the object lifetime handling, but left the comparison unchanged. The old != meant "continue past this entry"; after the refactor it meant "kill this entry". As a result, a single ACPI IPMI interface is never removed when its SMI disappears. If multiple interfaces are tracked, the first interface whose number differs from iface is removed instead, while the interface that actually disappeared remains on driver_data.ipmi_devices. The stale entry is not marked dead and can continue to be selected for ACPI IPMI transactions. It can also prevent the same ACPI handle from being registered again. Change the comparison to == so ipmi_bmc_gone() removes exactly the interface reported as gone by the SMI watcher. This restores the pre-a1a69b297e47 behavior and is the correct interface matching logic. Fixes: a1a69b297e47 ("ACPI / IPMI: Fix race caused by the unprotected ACPI IPMI user") Signed-off-by: Xu Rao Link: https://patch.msgid.link/B486593E06E6F6E0+20260616093621.1039943-1-raoxu@uniontech.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8dcf676092ff48a75e0efe14bd2b678b4cd7f26d Author: Andy Shevchenko Date: Wed Jun 17 11:05:55 2026 +0200 ACPI: resource: Amend kernel-doc style [ Upstream commit 78ad5c7722b7bed9d35ffc5b45eb0f12e2c22fee ] The functions are referred as func() in the kernel-doc. The % (percent) character makes the rendering for constants as described in the respective documentation. Amend all these. Fixes: 8e345c991c8c ("ACPI: Centralized processing of ACPI device resources") Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260617090555.2648709-1-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 172e690bab7a965effcb2448ec3f20dd4dc990d2 Author: Ricardo Neri Date: Sat Jun 13 15:17:47 2026 -0700 thermal: intel: Fix dangling resources on thermal_throttle_online() failure [ Upstream commit b91d287fa7a1ba0727eed5823c6ee4924ee5fa31 ] The function thermal_throttle_add_dev() may fail and abort a CPU hotplug online operation. Since the failure occurs within the online callback, thermal_throttle_online(), the CPU hotplug framework does not invoke the corresponding offline callback. As a result, the hardware and software resources set up during the failed operation are not torn down. Since only thermal_throttle_add_dev() can fail, call it before setting up the rest of the resources. Fixes: f6656208f04e ("x86/mce/therm_throt: Optimize notifications of thermal throttle") Signed-off-by: Ricardo Neri Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-1-3a26d1e47fc8@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 02f1d4b40eb42d112cb079fe55c9899004086d64 Author: Breno Leitao Date: Tue Jun 9 06:15:53 2026 -0700 arm64/hw_breakpoint: reject unaligned watchpoints that would truncate BAS [ Upstream commit 4cc70f75853bebac022334b6a86b953348072f74 ] hw_breakpoint_arch_parse() positions the BAS bit pattern in hw->ctrl.len with offset = hw->address & alignment_mask; /* 0..7 */ hw->ctrl.len <<= offset; ctrl.len is an 8-bit bitfield (struct arch_hw_breakpoint_ctrl::len is u32 :8), so the shift silently drops any bits past bit 7. For non-compat AArch64 watchpoints the offset is unbounded relative to ctrl.len: a perf_event_open(PERF_TYPE_BREAKPOINT) caller asking for HW_BREAKPOINT_W with bp_addr=page+1 and bp_len=HW_BREAKPOINT_LEN_8 ends up with 0xff << 1 = 0x1fe, stored as 0xfe. The kernel programs WCR.BAS=0xfe and the hardware watches bytes [1..7] instead of the requested [1..8] -- the eighth byte is silently dropped. The syscall still returns success, leaving userspace to discover the gap by empirical probing. The same class affects HW_BREAKPOINT_LEN_{2,4} when offset pushes the high BAS bit past bit 7 (e.g. LEN_4 with offset=5 yields 0xe0 instead of 0x1e0). No memory-safety impact -- the value is masked into 8 bits before encoding -- but debuggers and perf users observe missed events on bytes they thought they were watching. The AArch32 branch immediately above already rejects unrepresentable (offset, len) combinations via an explicit switch. Mirror that for the non-compat branch by checking that the shifted pattern fits in the BAS field, returning -EINVAL when it does not. GDB and similar debuggers are unaffected by the stricter check. aarch64_linux_set_debug_regs() already treats EINVAL on NT_ARM_HW_WATCH as a downgrade signal: it clears kernel_supports_any_contiguous_range, calls aarch64_downgrade_regs() to round the BAS up to a legacy 0x01/03/0f/ff mask with an aligned base, and retries -- the same fallback path that PR-20207 introduced. The new -EINVAL is therefore reachable only from a raw perf_event_open() that pairs an unaligned base with an oversized bp_len, which is precisely the bug. Reproducer: struct perf_event_attr a = { .type = PERF_TYPE_BREAKPOINT, .size = sizeof(a), .bp_type = HW_BREAKPOINT_W, .bp_addr = (uintptr_t)(buf + 1), .bp_len = HW_BREAKPOINT_LEN_8, .exclude_kernel = 1, .exclude_hv = 1, }; int fd = perf_event_open(&a, 0, -1, -1, 0); /* before this fix: succeeds, watches 7 bytes (buf+1..buf+7) */ /* after this fix: fails with EINVAL */ Fixes: b08fb180bb88 ("arm64: Allow hw watchpoint at varied offset from base address") Signed-off-by: Breno Leitao Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit fde42e9f5c591cc2a26ffa68c7dc02c78e8ca235 Author: Arnd Bergmann Date: Thu Jun 11 15:21:44 2026 +0200 arm64: static_call: include asm/insns.h [ Upstream commit 998d4d789d2d625e1d8c77c1b6c3951e30e81bb0 ] I came a cross a missing declaration in a randconfig build: arch/arm64/kernel/static_call.c:16:5: error: call to undeclared function 'aarch64_insn_adrp_get_offset'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 16 | aarch64_insn_adrp_get_offset(le32_to_cpup(tramp + 4)) + | ^ Include the header that contains this definition explicitly, rather than relying on it to come indirectly through another header. Fixes: 54ac9ff8f119 ("arm64: Use static call trampolines when kCFI is enabled") Signed-off-by: Arnd Bergmann Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7f8d816a9aa2729d270418f00c9ef5e85bfc1b31 Author: Lorenzo Bianconi Date: Mon Jun 15 11:18:25 2026 +0200 netfilter: flowtable: fix and simplify IP6IP6 tunnel handling [ Upstream commit f4c2d8668d85ed125985da663c824a9c25498257 ] Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments. Fixes: d98103575dcdd ("netfilter: flowtable: Add IP6IP6 rx sw acceleration") Signed-off-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 68286258698e15fe75073fb8d017003f8e493db1 Author: Cen Zhang Date: Fri Jun 19 01:00:10 2026 +0800 ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints [ Upstream commit f199c8a8bdd54296d3458777e70fe82a78bd9817 ] MIDI 2.0 input URBs are started during snd_usb_midi_v2_create(). A later setup failure can still jump to snd_usb_midi_v2_free(), which currently frees each endpoint and its coherent URB buffers without first stopping the submitted URBs. A completion can then dereference the embedded URB context and endpoint state after they have been freed, or try to resubmit from the stale endpoint. This was observed as a KASAN slab-use-after-free in input_urb_complete(). The buggy scenario involves two paths, with each column showing the order within that path: probe error path: USB completion path: 1. start_input_streams() submits 1. The HCD still owns a input URBs. submitted input URB. 2. A later setup helper returns 2. input_urb_complete() runs an error. with urb->context in ep. 3. snd_usb_midi_v2_free() frees 3. The completion reads ep endpoint storage and URB buffers. state and can requeue URBs. Make the endpoint destructor follow the same teardown ordering used for disconnect when the endpoint has not already been disconnected: publish ep->disconnected, kill the URBs synchronously, and drain the endpoint before freeing URB buffers and endpoint storage. The guard avoids repeating the stop sequence after the normal snd_usb_midi_v2_disconnect_all() path, while still synchronizing the direct MIDI 2.0 create-error free path. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in input_urb_complete+0x37/0x1b0 Workqueue: usb_hub_wq hub_event RIP: 0010:_raw_spin_unlock_irq+0x2e/0x50 Read of size 8 Call trace: dump_stack_lvl+0x77/0xb0 print_report+0xce/0x5f0 input_urb_complete+0x37/0x1b0 (sound/usb/midi2.c:186) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __usb_hcd_giveback_urb+0x112/0x1d0 dummy_timer+0xaaa/0x19a0 lock_is_held_type+0x9a/0x110 __lock_acquire+0x467/0x28b0 mark_held_locks+0x40/0x70 _raw_spin_unlock_irqrestore+0x44/0x60 lockdep_hardirqs_on_prepare+0xbb/0x1a0 __hrtimer_run_queues+0x101/0x520 hrtimer_run_softirq+0xd0/0x130 handle_softirqs+0x15b/0x670 __irq_exit_rcu+0xd0/0x170 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Fixes: d9c99876868c ("ALSA: usb-audio: Create UMP blocks from USB MIDI GTBs") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260618170010.191433-1-zzzccc427@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d9ac4239157e6ce3b61afc09ced3517349c92c5e Author: Daniel Zahka Date: Wed Jun 17 03:39:49 2026 -0700 eth: fbnic: take netif_addr_lock_bh() around rx mode address programming [ Upstream commit 96e7f9122aae0ed000ee321f324b812a447906d9 ] When __fbnic_set_rx_mode() is called from contexts other than .ndo_set_rx_mode_async(), the uc and mc addr lists are accessed without the addr lock that __hw_addr_sync_dev() and __hw_addr_unsync_dev() require. Wrap these unprotected accesses with netif_addr_lock_bh(). fbnic_clear_rx_mode() has similar issues. Fixes: eb690ef8d1c2 ("eth: fbnic: Add L2 address programming") Signed-off-by: Daniel Zahka Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260617-linux-fbnic-hwaddr-v1-1-3f9f5dee7f99@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 41b70eff03924e7aa1dae76c4c33abf27bf8eea1 Author: Ido Schimmel Date: Wed Jun 17 13:43:23 2026 +0300 selftests: vlan_bridge_binding: Fix flaky operational state check [ Upstream commit 4045f1c3d68ef4b589ae2587e6ff66ce8017daf2 ] check_operstate() busy waits for up to one second for the operational state to change to the expected state. This is not enough since carrier loss events can be delayed by the kernel for up to one second (see __linkwatch_run_queue()), leading to sporadic failures. Fix by increasing the busy wait period to two seconds. Fixes: dca12e9ab760 ("selftests: net: Add a VLAN bridge binding selftest") Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20260616092733.3a31be4d@kernel.org/ Signed-off-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260617104323.1069457-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b17f320893a415dcc94238a5f9c81452869bbf3 Author: Breno Leitao Date: Tue Jun 16 09:09:52 2026 -0700 netconsole: don't drop the last byte of a full-sized message [ Upstream commit c0ebe492329a4d29592e2240df17e56724849f1f ] nt->buf is exactly MAX_PRINT_CHUNK bytes, but scnprintf() reserves one byte for its NUL terminator, so a non-fragmented payload of exactly MAX_PRINT_CHUNK loses its last byte (emitted as a stray NUL in the release path). Grow nt->buf to MAX_PRINT_CHUNK + 1 and bound the scnprintf() calls with sizeof(nt->buf); the transmitted length stays capped at MAX_PRINT_CHUNK. Alternatively, nt->buf could be left at MAX_PRINT_CHUNK and the NUL byte reserved by routing exactly-MAX_PRINT_CHUNK payloads to fragmentation ('len < MAX_PRINT_CHUNK'), at the cost of fragmenting those messages. But it would look less sane, thus the current approach. Fixes: c62c0a17f9b7 ("netconsole: Append kernel version to message") Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260616-max_print_chunk-v1-1-8dc125d67083@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 825de39f0c35a112148799b3cbe45af3766c018a Author: Yun Zhou Date: Tue Jun 16 20:30:57 2026 +0800 flow_dissector: check device type before reading ETH_ADDRS [ Upstream commit bf6e8af2c8be77489bedeae9f8a9654cb710e500 ] __skb_flow_dissect() unconditionally reads 12 bytes from eth_hdr(skb) when FLOW_DISSECTOR_KEY_ETH_ADDRS is requested. This assumes the skb has a valid Ethernet header at mac_header, which is not always the case. The problem can be triggered by: 1. Creating a TUN device in L3 mode (IFF_TUN, hard_header_len=0) 2. Attaching a multiq qdisc with a flower filter matching on eth_src 3. Sending a packet through AF_PACKET Since TUN in L3 mode has no link-layer header, mac_header points to the L3 data area. The flow dissector reads 12 bytes of uninitialized skb memory, which then propagates through fl_set_masked_key() and is used as a rhashtable lookup key in __fl_lookup(), as reported by KMSAN. Rejecting the filter in the control path (at tc filter add time) is not feasible because TC filter blocks can be shared between arbitrary devices -- a filter installed on an Ethernet device may later classify packets on a headerless device through a shared block. The device association is not fixed at filter creation time. Fix this by gating the memcpy on dev->type == ARPHRD_ETHER, which ensures only true Ethernet-framed packets have their addresses read. This is more precise than the previous hard_header_len >= 12 check, which would incorrectly pass for non-Ethernet link types like IPoIB (ARPHRD_INFINIBAND, hard_header_len=24) and FDDI (hard_header_len=21) whose L2 headers are not in Ethernet format. Additionally check skb_mac_header_was_set() to guard against the pathological case where mac_header is the unset sentinel (~0U), which would cause eth_hdr() to return a wild pointer. For the act_mirred redirect case (Ethernet packet redirected to a non-Ethernet device sharing a TC block), zeroing the key is the correct behavior: the packet is now being classified on the target device, where Ethernet address matching is not semantically meaningful. Note: on non-Ethernet devices, the zeroed key will match a filter configured with all-zero MAC addresses. This is an improvement over the previous behavior where uninitialized memory could randomly match any filter. Reported-by: syzbot+fa2f5b1fb06147be5e16@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fa2f5b1fb06147be5e16 Fixes: 67a900cc0436 ("flow_dissector: introduce support for Ethernet addresses") Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260616123057.482154-1-yun.zhou@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9acbcb89190a311bd76fe45cf3ce284f7595978e Author: Lukasz Raczylo Date: Tue Jun 16 15:23:03 2026 +0200 net: macb: add TX stall timeout callback to recover from lost TSTART write [ Upstream commit e438ec3e9e95cd3f49a8120e5f63ae3f9606e6fa ] The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on the TX queue. While the exact root cause is not yet fully understood, it is likely related to a hardware issue where a TSTART write to the NCR register is missed, preventing the transmission from being kicked off. Implement a timeout callback to handle TX queue stalls, triggering the existing restart mechanism to recover. Link: https://lore.kernel.org/all/20260514215459.36109-1-lukasz@raczylo.com/ Fixes: dc110d1b23564 ("net: cadence: macb: Add support for Raspberry Pi RP1 ethernet controller") Signed-off-by: Lukasz Raczylo Co-developed-by: Steffen Jaeckel Signed-off-by: Steffen Jaeckel Co-developed-by: Andrea della Porta Signed-off-by: Andrea della Porta Reviewed-by: Nicolai Buchwitz Reviewed-by: Théo Lebrun Link: https://patch.msgid.link/468f480454a314303bac6a54780b153f689f2267.1781598350.git.andrea.porta@suse.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f7cd1e26d2f1766438edc9b9254f2c618f9ae98 Author: Wayen Yan Date: Tue Jun 16 19:52:36 2026 +0800 net: airoha: fix foe_check_time allocation size [ Upstream commit 5c121ee635680c93d7074becf14cfbaac140f80d ] foe_check_time is declared as u16 pointer but was allocated with only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16). When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2, it writes beyond the allocated buffer, causing heap buffer overflow and potential kernel crash. Fixes: 6d5b601d52a2 ("net: airoha: ppe: Dynamically allocate foe_check_time array in airoha_ppe struct") Signed-off-by: Wayen Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/178161119471.2163752.14373384830691569758@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f5adcb9245ae131474b8b0a7927816426153d49c Author: Cosmin Ratiu Date: Tue Jun 16 14:06:33 2026 +0300 devlink: Fix parent ref leak on tc-bw failure [ Upstream commit ba81a8b80f042038b9f73a4e5bb135de890b59bb ] When a node is created via rate-new with tc-bw and a parent node, devlink_nl_rate_set() executes the sequence of ops. It bails out on the first failure and doesn't rollback anything. For most things that is fine (setting some numbers), but the parent set can leak if there's another failure after that. That is precisely what happens when parent setting isn't the last block in the function. After the referenced "Fixes" commit, when tc-bw fails to be set the function bails out after having set the parent and incremented its refcount. There are two callers: - devlink_nl_rate_set_doit() is fine, it just reports the error. - but devlink_nl_rate_new_doit() frees the newly created node and leaks the parent refcnt. Fix that by reordering the blocks so parent setting is last and adding a comment explaining this so future modification preserve the ordering (hopefully). Fixes: 566e8f108fc7 ("devlink: Extend devlink rate API with traffic classes bandwidth management") Signed-off-by: Cosmin Ratiu Reviewed-by: Carolina Jubran Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260616110633.1449432-3-cratiu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21f7e96cf1645596a21c2b94213eb4d3e9751b44 Author: Cosmin Ratiu Date: Tue Jun 16 14:06:32 2026 +0300 devlink: Fix parent ref leak in devl_rate_node_create() [ Upstream commit ba45106342bbdd905651cb9fcefb8c11871d4c25 ] In the original commit the function bails out on kstrdup failure, forgetting to decrement the refcnt of the parent. Fix that by moving the parent refcnt setting after kstrdup. Fixes: caba177d7f4d ("devlink: Enable creation of the devlink-rate nodes from the driver") Signed-off-by: Cosmin Ratiu Reviewed-by: Carolina Jubran Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260616110633.1449432-2-cratiu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbb6321c297776422fa20751f6a9906dfe89887f Author: Ioana Ciornei Date: Tue Jun 16 13:54:30 2026 +0300 dpaa2-switch: fix VLAN upper check not rejecting bridge join [ Upstream commit ed2294f94e34e97342850c40b320833d881c3819 ] The blamed commit refactored the prechangeupper event handling but failed to actually return an error in case dpaa2_switch_prevent_bridging_with_8021q_upper() detected a 802.1q upper on a port which tries to join a bridge. Fix this by returning err instead of 0. Fixes: 45035febc495 ("net: dpaa2-switch: refactor prechangeupper sanity checks") Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20260616105430.3725910-1-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e6b8463b7d791f3886d7584259d6e9f06a69f12e Author: Xiang Mei Date: Mon Jun 15 21:28:37 2026 -0700 virtio-net: fix len check in receive_big() [ Upstream commit 9e5ad06ea826322ce8c58b4a68442a96f600c3c4 ] receive_big() bounds the device-announced length by (big_packets_num_skbfrags + 1) * PAGE_SIZE. That is still too loose: add_recvbuf_big() sets sg[1] to start at offset sizeof(struct padded_vnet_hdr) into the first page, so the chain actually carries hdr_len + (PAGE_SIZE - sizeof(padded_vnet_hdr)) + big_packets_num_skbfrags * PAGE_SIZE bytes -- 20 bytes less than the check allows for the common hdr_len == 12 case. A malicious virtio backend can announce a len in that gap. page_to_skb() then walks one frag past the page chain, storing a NULL page->private into skb_shinfo()->frags[MAX_SKB_FRAGS], which is both an out-of-bounds write past the static frag array and a NULL frag handed up the rx path. Bound len by the size add_recvbuf_big() actually advertised. Fixes: 0c716703965f ("virtio-net: fix received length check in big packets") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Xuan Zhuo Acked-by: Michael S. Tsirkin Reviewed-by: Bui Quang Minh Link: https://patch.msgid.link/20260616042837.2249468-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d654af91739a0b21c17044e8c726274cd9c48d37 Author: Quang Nguyen Date: Thu Jun 18 09:19:30 2026 +0100 spi: rpc-if: Use correct device for hardware reinitialization on resume [ Upstream commit 7b25dbafa2fce50b1a48c1d057adb35da3563f9b ] rpcif_spi_resume() currently passes the SPI controller device to rpcif_hw_init(), but the function should be called with the RPC interface device. Retrieve the rpcif private data from the SPI controller and pass rpc->dev instead. Also propagate the return value of rpcif_hw_init() so that a failure during resume is properly reported rather than silently ignored. Fixes: ad4728740bd6 ("spi: rpc-if: Add resume support for RZ/G3E") Signed-off-by: Quang Nguyen Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260618081932.172168-1-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aa80fca32cf7e0202bc8090314629c1d5adbb04c Author: Mark Tomlinson Date: Thu Apr 30 14:16:28 2026 +1200 PCI: iproc: Restore .map_irq() for the platform bus driver [ Upstream commit 3c2e6cc6affa8acdb99a580be1f8f297edf54204 ] Commit b64aa11eb2dd ("PCI: Set bridge map_irq and swizzle_irq to default functions") moved the assignment of default .map_irq() callback to devm_of_pci_bridge_init() and removed the initialization of 'iproc_pcie::map_irq' in platform bus driver. This led to the callback getting assigned the NULL pointer for platform bus driver, thereby breaking the INTx functionality, since 'iproc_pcie::map_irq' overrides the 'pci_host_bridge::map_irq' callback in iproc_pcie_setup(). This issue only affected the iproc platform bus driver as this driver relies on the default callback for non-PAXC controllers. iproc-brcm driver was already providing the custom mapping function, so it was unaffected. Restore the original (and intended) behaviour to use the default map_irq function by removing the local 'iproc_pcie::map_irq' pointer and directly assigning the 'pci_host_bridge::map_irq' callback in iproc-bcma driver. This ensures that the default 'map_irq' callback is used for platform bus driver and only iproc-brcm driver overrides it with a custom one. Fixes: b64aa11eb2dd ("PCI: Set bridge map_irq and swizzle_irq to default functions") Signed-off-by: Mark Tomlinson [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Acked-by: Ray Jui Link: https://patch.msgid.link/20260430021628.1343154-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Sasha Levin commit ec6fb1ecada8ddfc3d0e1728e4792d16ae55dcdb Author: Michael Bommarito Date: Wed Jun 17 22:51:26 2026 -0400 ALSA: usb-audio: qcom: clear opened when stream enable fails [ Upstream commit 3c7af07943b2718087ae791cad450af5cf646d90 ] On enable, subs->opened is set before the service_interval is validated; an invalid interval jumps to the response label without clearing it, so the substream is wedged at -EBUSY until a disable or disconnect. Clear subs->opened on the enable error path. Fixes: 326bbc348298a ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260618025126.1862954-3-michael.bommarito@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a22356d1f731553e99aa2707dbd38c659bdd28d8 Author: Michael Bommarito Date: Wed Jun 17 22:51:25 2026 -0400 ALSA: usb-audio: qcom: reject stream disable with no active interface [ Upstream commit bdb640be82e645e2828731648f485224d0c2587b ] handle_uaudio_stream_req() resolves an interface index with info_idx_from_ifnum(), which returns -EINVAL when no interface matches. The enable branch and the response: cleanup label both guard against a negative index, but the disable branch does not: it forms info = &uadev[pcm_card_num].info[info_idx] and dereferences it. uadev[].info is a pointer allocated only when a stream is first enabled, so a negative info_idx on the disable path is unsafe in two ways: - If the card was never enabled, .info is NULL and &info[-EINVAL] is a wild pointer; reading info->data_ep_pipe faults (kernel oops). - If the card was enabled at least once (.info allocated) and the disable names an interface that does not match, &info[-EINVAL] points before the allocation; info->data_ep_pipe / info->sync_ep_pipe are an out-of-bounds slab read and, when non-zero, an out-of-bounds 4-byte write (both pipe fields are cleared to 0). That is memory corruption, not just a NULL dereference. The request is reachable from unprivileged local userspace over AF_QIPCRTR. Reject a disable request with no resolved interface, matching the guard the enable path already has. Fixes: 326bbc348298a ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260618025126.1862954-2-michael.bommarito@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f09a245f33e567b604efa1960b7a2d25dd9c8713 Author: Xin Long Date: Mon Jun 15 15:36:30 2026 -0400 sctp: hold socket lock when dumping endpoints in sctp_diag [ Upstream commit 7d8297e26b4e20b5d1c3c3fe51fe81a1c7fbc823 ] SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative. Reported-by: Zero Day Initiative Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Xin Long Link: https://patch.msgid.link/4c1b49ab87e0f7d552ebd8172b364b1994e913c9.1781552190.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 794a0d8bdbb39e083ed42caccb86d687a9b53570 Author: Jakub Kicinski Date: Mon Jun 15 17:30:46 2026 -0700 net: psample: fix info leak in PSAMPLE_ATTR_DATA [ Upstream commit aedd02af1f8b0bceb7f42f5a21c41634ca9ed390 ] psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B. Fixes: 6ae0a6286171 ("net: Introduce psample, a new genetlink channel for packet sampling") Reported-by: Weiming Shi Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20260616003046.1099490-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e19d38d397d440a0dbf2eeb36c93d5fa0955381e Author: Ratheesh Kannoth Date: Mon Jun 15 09:01:57 2026 +0530 octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug level [ Upstream commit 4f6ac65e81625165257131ec2574bb6bb09bd7d8 ] npc_install_mcam_drop_rule() used dev_err() after a successful rvu_mbox_handler_npc_mcam_write_entry() call, so normal installs appeared as errors in dmesg. Use dev_dbg() for the success path and keep dev_err() for real failures. Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM") Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260615033157.535237-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 452ec5058ea4ed63adae8d6beeac9ee687fe8061 Author: Ratheesh Kannoth Date: Mon Jun 15 08:37:04 2026 +0530 octeontx2-pf: Fix leak of SQ timestamp buffer on teardown [ Upstream commit a056db30de92945ff8ee6033096678bfbae878e3 ] The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers. Fixes: c9c12d339d93 ("octeontx2-pf: Add support for PTP clock") Cc: Aleksey Makarov Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260615030704.504536-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 043ed6924c632954f579054b81a68f2c847f29d4 Author: Tianchen Ding Date: Mon Jun 1 10:32:51 2026 +0800 selftests/ftrace: Fix trace_marker_raw test on 64K page kernels [ Upstream commit 65f26d15f7db80b0a3f995c518cdddb50e6dea99 ] On ARM64 kernels with 64K pages, the trace_marker_raw test fails because bash's printf builtin uses stdio buffering which splits output into multiple small write() calls to the tracefs file. Since each individual write is within TRACE_MARKER_MAX_SIZE (4096), they all succeed, causing the "too big" write test to incorrectly pass. Fix by writing through dd with iflag=fullblock to guarantee a single atomic write() syscall to trace_marker_raw. Link: https://lore.kernel.org/r/20260601023251.1916483-1-dtcccc@linux.alibaba.com Fixes: 37f46601383a ("selftests/tracing: Add basic test for trace_marker_raw file") Signed-off-by: Tianchen Ding Reviewed-by: Steven Rostedt Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e5c6debdad284f361f8a15255664930e00dc1d07 Author: Christian Marangi Date: Mon Jun 15 17:11:00 2026 +0200 net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create [ Upstream commit e4b4d8410c7ccea25f4b332a077c6b9f5d263228 ] Everything configured in phylink_config it's assumed to be set before calling phylink_create() to permit correct parsing of all the different modes and capabilities. Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY") while introducing support for 2.5G phy for MT7988, probably due to an auto-rebase, placed the configuration of the INTERNAL interface mode for the supported_interfaces for phylink_config right after phylink_create() introducing a possible problem with supported interfaces parsing. While this doesn't currently create any problem/bug, move setting this bit before phylink_create() to prevent any possible regression in future code change in phylink core. Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY") Signed-off-by: Christian Marangi Reviewed-by: Maxime Chevallier Reviewed-by: Daniel Golle Link: https://patch.msgid.link/20260615151106.15438-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bc88744dc55615a1be8ab1d07ff2cec1d31adfa1 Author: Thadeu Lima de Souza Cascardo Date: Mon Jun 8 16:22:35 2026 -0300 drm/amdgpu: initialize irq.lock spinlock earlier [ Upstream commit a2b270c0ecf6d95bcd14ef4c20d0301a88143ff5 ] If there is an early failure during amdgpu probe, like missing firmware, it will end up calling amdgpu_irq_disable_all, which takes irq.lock spinlock without it being initialized. Initializing irq.lock earlier at amdgpu_device_init fixes the issue. [ 79.334079] INFO: trying to register non-static key. [ 79.334081] The code is fine but needs lockdep annotation, or maybe [ 79.334083] you didn't initialize this object before use? [ 79.334084] turning off the locking correctness validator. [ 79.334088] CPU: 2 UID: 0 PID: 1819 Comm: bash Not tainted 7.1.0-rc5-gfd06300b2348 #96 PREEMPT 8e8f461221633dae3c832d6689eaf0546c0ed4cd [ 79.334092] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0133 08/05/2024 [ 79.334094] Call Trace: [ 79.334095] [ 79.334097] dump_stack_lvl+0x5d/0x80 [ 79.334103] register_lock_class+0x7af/0x7c0 [ 79.334109] __lock_acquire+0x416/0x2610 [ 79.334114] lock_acquire+0xcf/0x310 [ 79.334117] ? amdgpu_irq_disable_all+0x3b/0xf0 [amdgpu c88bab43d391d519ad0d5c8e5a099b4aceefa180] [ 79.334503] ? _raw_spin_lock_irqsave+0x53/0x60 [ 79.334508] _raw_spin_lock_irqsave+0x3f/0x60 [ 79.334510] ? amdgpu_irq_disable_all+0x3b/0xf0 [amdgpu c88bab43d391d519ad0d5c8e5a099b4aceefa180] [ 79.334881] amdgpu_irq_disable_all+0x3b/0xf0 [amdgpu c88bab43d391d519ad0d5c8e5a099b4aceefa180] [ 79.335240] amdgpu_device_fini_hw+0x90/0x32c [amdgpu c88bab43d391d519ad0d5c8e5a099b4aceefa180] [ 79.335704] amdgpu_driver_load_kms.cold+0x22/0x44 [amdgpu c88bab43d391d519ad0d5c8e5a099b4aceefa180] [ 79.336159] amdgpu_pci_probe+0x204/0x440 [amdgpu c88bab43d391d519ad0d5c8e5a099b4aceefa180] [ 79.336494] local_pci_probe+0x3c/0x80 [ 79.336500] pci_call_probe+0x55/0x2e0 [ 79.336505] ? _raw_spin_unlock+0x2d/0x50 [ 79.336508] ? pci_match_device+0x157/0x180 [ 79.336512] pci_device_probe+0x9b/0x170 [ 79.336516] really_probe+0xd5/0x370 [ 79.336521] __driver_probe_device+0x84/0x150 [ 79.336525] device_driver_attach+0x47/0xb0 [ 79.336528] bind_store+0x73/0xc0 [ 79.336531] kernfs_fop_write_iter+0x176/0x250 [ 79.336536] vfs_write+0x24d/0x560 [ 79.336542] ksys_write+0x71/0xe0 [ 79.336546] do_syscall_64+0x122/0x710 [ 79.336550] ? do_syscall_64+0xd1/0x710 [ 79.336553] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 79.336557] RIP: 0033:0x7f92fd675006 [ 79.336561] Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 [ 79.336562] RSP: 002b:00007ffe4fa867a0 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ 79.336565] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f92fd675006 [ 79.336567] RDX: 000000000000000d RSI: 000055b2dfce59b0 RDI: 0000000000000001 [ 79.336568] RBP: 00007ffe4fa867c0 R08: 0000000000000000 R09: 0000000000000000 [ 79.336569] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d [ 79.336570] R13: 000055b2dfce59b0 R14: 00007f92fd7ca5c0 R15: 000055b2dfdbaf70 [ 79.336574] Fixes: 9950cda2a018 ("drm/amdgpu: drop the drm irq pre/post/un install callbacks") Reviewed-by: Tvrtko Ursulin Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Alex Deucher (cherry picked from commit 7dba3e10ecdeec85208e255853fcd3890880b10e) Signed-off-by: Sasha Levin commit e33a3bd5cb8d0cf1557dee014115f812c9686130 Author: Mario Limonciello Date: Fri Jun 12 21:22:04 2026 -0500 drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm [ Upstream commit 8fa5655da368d0306c03e9dc9cda8ae2a7840926 ] The cleanup tail of kfd_criu_resume_svm() walks svms->criu_svm_metadata_list and kfree()s each struct criu_svm_metadata without removing it from the list. The list head is left pointing at freed kmalloc-96 objects. A second AMDKFD_IOC_CRIU_OP from the same process re-enters: list_empty() reads the dangling ->next (use-after-free), the loop walks freed entries, and each is kfree()'d again (double-free). This is reachable by an unprivileged render-group user via /dev/kfd with no capabilities required. Add list_del() before the kfree() so the list is properly emptied. The list_for_each_entry_safe() iterator already caches the next pointer, so unlinking during the walk is safe. Fixes: 2a909ae71871 ("drm/amdkfd: CRIU resume shared virtual memory ranges") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 6322d278a298e2c1430b9d2697743d3a04b788b1) Signed-off-by: Sasha Levin commit db803223edc4def4d97a753191fb3a7ffe3981f1 Author: Matthew Schwartz Date: Thu Jun 11 08:44:38 2026 -0700 drm/amd/display: Fix mem_type change detection for async flips [ Upstream commit 8e792f018e10e68f488f279fbd4f38009a2e066d ] [Why] amdgpu_dm_crtc_mem_type_changed() fetches the "old" and "new" plane state with two drm_atomic_get_plane_state() calls, which both return the new state. It compares a state against itself, so it never detects a mem_type change and never rejects the async flip. On DCN 3.0.1, this shows up as intermittent corruption when a single DCC plane is scanned out with immediate flips under gamescope and its buffer moves between the VRAM carveout and GTT. [How] Use drm_atomic_get_old_plane_state() and drm_atomic_get_new_plane_state() to compare the actual old and new states. These return NULL rather than an error pointer for a plane that is not part of the commit, so the IS_ERR() check becomes a NULL check that skips those planes, such as an unmodified cursor still in the CRTC's plane_mask. Fixes: 4caacd1671b7 ("drm/amd/display: Do not elevate mem_type change to full update") Reviewed-by: Harry Wentland Reviewed-by: Melissa Wen Signed-off-by: Matthew Schwartz Signed-off-by: Alex Deucher (cherry picked from commit 13158e5dbd896281f3e9982b5437cffa5fd621b2) Signed-off-by: Sasha Levin commit db70b4a08211b9134d0ed65216a8f8fc7e783fbb Author: Roman Li Date: Wed May 20 16:50:34 2026 -0400 drm/amd/display: Skip PHY SSC reduction on some 8K panels [ Upstream commit fe7945d092a1d3c340febc2ab176cee50d0f6c80 ] [Why] Some 8K displays cannot tolerate the reduced phy ssc value at high link utilization and show corruption or black screen. [How] Add an EDID panel-id quirk to utilize existing skip_phy_ssc_reduction flag. To pass the link into the quirk handler, change the signature of apply_edid_quirks() to take link as an argument. The dev local in dm_helpers_parse_edid_caps() becomes unused and is removed. Fixes: 5fa62c87cffd ("drm/amd/display: Add option to disable PHY SSC reduction on transmitter enable") Reviewed-by: Alex Hung Signed-off-by: Roman Li Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 144169e7be0831e09958a906d08d1856751aa6c6) Signed-off-by: Sasha Levin commit 7f20ce7b2bcf6b85b8e160366ec0f2a3e55926c3 Author: Qiang Yu Date: Tue May 26 14:45:48 2026 +0800 drm/amdgpu: initialize iter.start in amdgpu_devcoredump_format [ Upstream commit 1c2d7a656655a50bd1b7227fb26d173959a1955d ] This fixes read /sys/class/drm/cardN/device/devcoredump/data return empty content sometimes. amdgpu_devcoredump_format() leaves struct drm_print_iterator's .start field uninitialized on the stack before passing it to drm_coredump_printer(). __drm_puts_coredump() compares the running .offset against .start to decide whether to skip or copy each chunk: if (iterator->offset < iterator->start) { if (iterator->offset + len <= iterator->start) { iterator->offset += len; return; } ... } Fixes: 4bbba79a7f1d ("drm/amdgpu: move devcoredump generation to a worker") Acked-by: Alex Deucher Signed-off-by: Qiang Yu Signed-off-by: Alex Deucher (cherry picked from commit cd6397b7af8262a380e188dc32e9de11ff897ed2) Signed-off-by: Sasha Levin commit 1d12ae8b079e173107abec0e5817332954c8e95f Author: Yunxiang Li Date: Thu Jun 4 12:59:11 2026 -0400 drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free [ Upstream commit 3f0cc1735273a57c5116710cf0202e12152f59cc ] amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO remap BOs (which are pinned at allocation time) before checking whether the BO is still mapped to the GPU. When the BO is still mapped, the function returns -EBUSY and leaves the BO alive, but it has already been unpinned. The BO is then unpinned again when it is finally freed during process teardown, triggering a ttm_bo_unpin() underflow warning: WARNING: CPU: 18 PID: 15066 at ttm/ttm_bo.c:650 amdttm_bo_unpin+0x6d/0x80 [amdttm] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] RIP: 0010:amdttm_bo_unpin+0x6d/0x80 [amdttm] Call Trace: amdgpu_bo_unpin+0x1a/0x90 [amdgpu] amdgpu_amdkfd_gpuvm_unpin_bo+0x31/0xb0 [amdgpu] amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3bf/0x460 [amdgpu] kfd_process_free_outstanding_kfd_bos+0xd4/0x170 [amdgpu] kfd_process_wq_release+0x109/0x1b0 [amdgpu] process_one_work+0x1e2/0x3b0 worker_thread+0x50/0x3a0 kthread+0xdd/0x100 ret_from_fork+0x29/0x50 Move the unpin after the mapped_to_gpu_memory check so it only happens once we are committed to freeing the BO. Fixes: d25e35bc26c3 ("drm/amdgpu: Pin MMIO/DOORBELL BO's in GTT domain") Signed-off-by: Yunxiang Li Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 927c5b2defb9b09856444d94bebfd056a002bd75) Signed-off-by: Sasha Levin commit e2ab48e8591d7bbd3981db62d3acf335085ef52d Author: Sen Wang Date: Tue Jun 16 18:33:22 2026 -0500 ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode [ Upstream commit fdf043f5f3bae150b678feae3d7bb1beed87ec14 ] The datasheet documents that when the PLL is disabled and dual-rate mode is enabled, only Q values {4, 8, 9, 12, 16} are valid for the CLKDIV bypass path; all other Q values produce invalid bitclock output. The existing loop iterates Q from 2 to 17 without this restriction, causing silent audio failure when an out-of-spec Q is picked. Restrict the Q search to the allowed set in dual-rate mode. Fixes: 4f9c16ccfa26 ("[ALSA] soc - tlv320aic3x - revisit clock setup") Suggested-by: Mir Jeffres Signed-off-by: Sen Wang Link: https://patch.msgid.link/20260616233322.873081-1-sen@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 77961e12ea16d9f8ba568c652ed2848c2a728b75 Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 15:55:33 2026 -0300 perf dso: Set standard errno on decompression failure [ Upstream commit 1a5f9334a45a6b0c1cd7341cc72a3b87adad1d27 ] dso__get_filename() sets errno to a negative custom DSO_LOAD_ERRNO value when kernel module decompression fails: errno = *dso__load_errno(dso); /* e.g. -9996 */ The caller __open_dso() then computes fd = -errno, producing a large positive value (9996) that looks like a valid file descriptor. This can cause close_data_fd() to close an unrelated fd used by another subsystem. Set errno to EIO instead. The detailed error code is already stored in dso__load_errno(dso) for diagnostic messages. Fixes: 1d6b3c9ba756a513 ("perf tools: Decompress kernel module when reading DSO data") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit aa967ae8b256b223a9ae6993f1dd1596ac76b8bf Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 15:25:11 2026 -0300 perf bpf: Validate array presence before casting BPF prog info pointers [ Upstream commit 5ebf4137d23a4fd6c0cc6a6fb766ee60d2b09193 ] Several functions cast bpf_prog_info fields (jited_ksyms, jited_func_lens, jited_prog_insns) from u64 to pointers and dereference them. These fields are only valid pointers if bpil_offs_to_addr() converted their file offsets to addresses, which only happens when the corresponding PERF_BPIL_* bits are set in info_linear->arrays. A crafted perf.data can leave these bits unset while setting non-zero counts and offset values, causing the functions to dereference raw file offsets as pointers. Add array bitmask validation to all perf.data processing paths: - __bpf_event__print_bpf_prog_info(): check JITED_KSYMS and JITED_FUNC_LENS (changed to take struct perf_bpil *) - machine__process_bpf_event_load(): check JITED_KSYMS - bpf_read(): check JITED_INSNS before memcpy from jited_prog_insns - dso__disassemble_filename(): check JITED_INSNS before returning jited_prog_insns pointer Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()") Reported-by: sashiko-bot Cc: Song Liu Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bfc764f9de658fd7751da61d32f3de5fa39a75ba Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 15:16:42 2026 -0300 perf c2c: Fix hist entry and format list leaks in c2c_he_free() [ Upstream commit fe68cf349fb343c0a7cb6c4fe6c3de4f4afe8d1c ] c2c_he_free() calls hists__delete_entries() which only walks the output-sorted entries tree. During c2c resort, when cacheline entries are merged and the redundant entry is freed, the inner hists have not been output-resorted yet, so hists->entries is empty. The actual inner hist_entry objects live in entries_in_array[] and entries_collapsed, which are never walked, leaking all inner hist_entry objects for every merged cacheline. Additionally, the dynamically allocated format entries on hists->list are never unregistered or freed. Fix both issues by switching to hists__delete_all_entries() which walks all rb_root trees, and calling perf_hpp__reset_output_field() to clean up format entries. Fixes: bf0e0d407ea09ce5 ("perf c2c report: Add sample processing") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 502ee1fe757aeaa0e1d0a56f3f42e7d2e5b88b7c Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 15:13:54 2026 -0300 perf c2c: Free format list entries when c2c_hists__init() fails [ Upstream commit 61a21d11afd8dd83b2260ae00541bed62a843219 ] When c2c_hists__init() fails partway through hpp_list__parse(), dynamically allocated format structures that were already added to hists->list are leaked because he__get_c2c_hists() frees the hists container without first unregistering the format entries. Call perf_hpp__reset_output_field() before freeing the hists container on the error path, matching what c2c_he_free() already does on the normal destruction path. Fixes: 17a7c5946d79a12c ("perf c2c report: Decode c2c_stats for hist entries") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 79b92b298b5cfaa805a28df11ccc45ca86344be3 Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 14:55:32 2026 -0300 perf cs-etm: Bounds-check CPU in cs_etm__get_queue() [ Upstream commit 9a989e60cc6e29d98aed2087425cba53bf4b392d ] cs_etm__get_queue() indexes etm->queues.queue_array[cpu] without validating that cpu is within nr_queues. When processing AUX_OUTPUT_HW_ID events, the cpu value comes from untrusted perf.data trace payload and flows through cs_etm__process_trace_id_v0_1() and cs_etm__queue_aux_fragment() without bounds checking, allowing an out-of-bounds read with a crafted file. Add a bounds check in cs_etm__get_queue() and NULL checks in all callers. Also add NULL checks for queue_array[i].priv in the queue iteration loops in cs_etm__map_trace_id_v0() and cs_etm__process_trace_id_v0_1() — after auxtrace_queues__grow() new entries are zero-initialized so .priv can be NULL. Add a get_cpu_data() NULL check in cs_etm__process_trace_id_v0_1(), matching the existing check in cs_etm__process_trace_id_v0(). Fixes: 77c123f53e97ad4b ("perf: cs-etm: Move traceid_list to each queue") Reported-by: sashiko-bot Cc: Adrian Hunter Cc: James Clark Cc: Leo Yan Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2d5a695a9d19b11c633607a937c4dd6a2a81c604 Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 14:40:36 2026 -0300 perf cs-etm: Require full global header in auxtrace_info size check [ Upstream commit 78d8ba680126f3545e8d0fba667e12d79fd4353b ] cs_etm__process_auxtrace_info() checks that header.size covers event_header_size + INFO_HEADER_SIZE (16 bytes total), but then accesses ptr[CS_PMU_TYPE_CPUS] at offset 24 from the start of the event. A crafted 16-byte auxtrace_info event passes the size check but reads out-of-bounds. Include CS_ETM_HEADER_SIZE in the minimum size check so that the global header entries (version, pmu_type_cpus, snapshot) are guaranteed to fit within the event. Fixes: 55c1de9973d66516 ("perf cs-etm: Print auxtrace info even if OpenCSD isn't linked") Reported-by: sashiko-bot Cc: Adrian Hunter Cc: James Clark Cc: Leo Yan Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f22dbfb71c3d1e4bcb81d9ffc992e8cec2186004 Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 14:16:45 2026 -0300 perf cs-etm: Validate num_cpu before metadata allocation [ Upstream commit 312d91329b8fc6989a916a3f9a12d0674167b7e4 ] cs_etm__process_auxtrace_info_full() reads num_cpu from untrusted perf.data and uses it to allocate the metadata pointer array: metadata = zalloc(sizeof(*metadata) * num_cpu); On 32-bit, sizeof(*metadata) is 4, so num_cpu = 0x40000000 overflows the multiplication to 0, causing zalloc(0) to return a valid zero-sized allocation followed by out-of-bounds writes in the population loop. Fix by computing priv_size early and using it to bound num_cpu: each CPU needs at least one u64 metadata entry, so num_cpu cannot exceed the total number of u64 entries in the event's private data area. Fixes: cd8bfd8c973eaff8 ("perf tools: Add processing of coresight metadata") Reported-by: sashiko-bot Cc: Adrian Hunter Cc: James Clark Cc: Leo Yan Cc: Tor Jeremiassen Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7c7245321599412d7013a6cd2c50fcd6f1209cf0 Author: Arnaldo Carvalho de Melo Date: Sat Jun 13 13:59:39 2026 -0300 perf machine: Use snprintf() for guestmount path construction [ Upstream commit fe63d3bca288c5bb983304efd5fc3a5ff3183403 ] machines__findnew() and machines__create_guest_kernel_maps() use sprintf() to build paths by prepending symbol_conf.guestmount. Both write into PATH_MAX stack buffers, but guestmount comes from user configuration and is not length-checked. A guestmount path at or near PATH_MAX causes a stack buffer overflow. Switch to snprintf() with sizeof() to prevent overflow. The subsequent access()/fopen() calls will fail on a truncated path. Fixes: a1645ce12adb6c9c ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5a03a2ee17e8259dde631ed84fd8322db06cb2ae Author: Eric Dumazet Date: Mon Jun 15 09:02:37 2026 +0000 xfrm: validate selector family and prefixlen during match [ Upstream commit 40f0b1047918539f0b0f795ac65e35336b4c2c78 ] syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow). Fixes: 3f0ab59e6537 ("xfrm: validate new SA's prefixlen using SA family when sel.family is unset") Reported-by: syzbot+9383b1ff0df4b29ca5e6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a2fbe35.be3f099c.2836ae.0018.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 7394a276f86939e23b6c3621b3d5d961efa0698a Author: Eric Dumazet Date: Fri Jun 12 05:56:34 2026 +0000 xfrm: annotate data-races around xfrm_policy_count[] and xfrm_policy_default[] [ Upstream commit 68de007d5ac9df0e3f4f187a179c5c842bb5a2be ] KCSAN reported a data race involving net->xfrm.policy_count access. Add missing READ_ONCE()/WRITE_ONCE() annotations on xfrm_policy_count and xfrm_policy_default. Fixes: 2518c7c2b3d7 ("[XFRM]: Hash policies when non-prefixed.") Reported-by: syzbot+d85ba1c732720b9a4097@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a2b9e96.99669fcc.12a77b.0006.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 041859fd55c81ea55e76d051e39b7b79975b8c7d Author: Herbert Xu Date: Fri Jun 12 12:58:59 2026 +0800 xfrm: Fix xfrm state cache insertion race [ Upstream commit ddd3d0132920319ac426e12456013eadbae67e15 ] The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path. Fixes: 81a331a0e72d ("xfrm: Add an inbound percpu state cache.") Reported-by: Zero Day Initiative Signed-off-by: Herbert Xu Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit f83ef148a94bd75a02c9238014b008e38822a604 Author: Xu Rao Date: Tue Jun 16 19:59:16 2026 +0800 ALSA: usb-audio: qcom: Free sideband sg_table objects [ Upstream commit 7d69804a35103a50852eae41bfe6a2e0061c68fd ] The Qualcomm USB audio offload driver obtains an endpoint transfer-ring table by calling xhci_sideband_get_endpoint_buffer(). This getter passes the endpoint ring to xhci_ring_to_sgtable(), which allocates the outer struct sg_table with kzalloc_obj(*sgt). The event-ring path is equivalent: xhci_sideband_get_event_buffer() also returns the result of xhci_ring_to_sgtable(). Inside xhci_ring_to_sgtable(), sg_alloc_table_from_pages() separately allocates the scatterlist storage referenced by sgt->sgl. The returned object therefore has two allocation layers: the outer struct sg_table and its internal scatterlist storage. The Qualcomm caller only invokes sg_free_table(sgt). sg_free_table() releases the scatterlist storage owned by the table, but it does not free the separately allocated outer struct sg_table. The local sgt pointer is then discarded, so every successful endpoint or event-ring query leaks the outer object. Call kfree(sgt) after sg_free_table(sgt) in both setup paths, after the required page and DMA addresses have been copied out. Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Signed-off-by: Xu Rao Link: https://patch.msgid.link/90B353283AA150C4+20260616115916.1222915-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9104559db16bf4b46a383d8111495856f83a4837 Author: Gao Xiang Date: Wed Jun 17 11:14:59 2026 +0800 erofs: call erofs_exit_ishare() before rcu_barrier() [ Upstream commit 289cf458a69ccda4a4aee2b0274d233d415814ca ] Ensure all inode free callbacks have completed before destroying the inode slab cache. Fixes: 5ef3208e3be5 ("erofs: introduce the page cache share feature") Reviewed-by: Hongbo Li Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit a6b17b34aedc34ce022bd5655f51ef8664d24de5 Author: Adrian Hunter Date: Tue Jun 16 14:37:51 2026 +0300 i3c: master: Add missing runtime PM get in dev_nack_retry_count_store() [ Upstream commit 79ce29e100ab3de0cad66eb48d32a7de4043e2ae ] Ensure the device is runtime resumed while updating the retry configuration to avoid accessing the controller while suspended. Call i3c_master_rpm_get() before accessing the controller in dev_nack_retry_count_store() and release it with i3c_master_rpm_put() afterwards. Fixes: 990c149c61ee4 ("i3c: master: Introduce optional Runtime PM support") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260616113752.196140-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b5d5cfea4f235f68b7ad9927a29381b5ed766580 Author: Adrian Hunter Date: Tue Jun 16 14:37:50 2026 +0300 i3c: master: Update dev_nack_retry_count under maintenance lock [ Upstream commit ab5f9c5cb527c03790a92142ad368881a9100aaf ] Protect master->dev_nack_retry_count against concurrent sysfs updates by updating it while holding the bus maintenance lock. Consequently, combine adjacent return statements into one. For consistency, read dev_nack_retry_count while holding the bus normaluse lock. Fixes: b58f47eb39268 ("i3c: add sysfs entry and attribute for Device NACK Retry count") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260616113752.196140-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7f29c063c53f0a8bc43fe8f6c256403938e3cf25 Author: Jisheng Zhang Date: Fri Jun 12 08:28:35 2026 +0800 spi: dw: fix wrong BAUDR setting after resume [ Upstream commit 66b6605bcea7af7aca3d1d858b9c5f14903f9f9a ] After resuming from suspend to ram, spi transfer stops working. Further debugging shows that the BAUDR register isn't correctly set, this is due to dws->current_freq doesn't match the HW BAUDR setting, specifically, the dws->current_freq equals to speed_hz, but BAUDR is 0. so the dw_spi_set_clk() in below code won't be called: if (dws->current_freq != speed_hz) { dw_spi_set_clk(dws, clk_div); dws->current_freq = speed_hz; } The mismatch comes from dw_spi_shutdown_chip() when suspending. Fix this mismatch by setting dws->current_freq to 0 as well when clearing BAUDR reg in dw_spi_shutdown_chip(). Fixes: e24c74527207 ("spi: controller driver for Designware SPI core") Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20260612002835.5240-1-jszhang@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a5c5676ad3b0588161d24f4091d6cbb49c4506e2 Author: Thomas Hellström Date: Thu Jun 4 09:45:00 2026 +0200 drm/xe: Fix wa_oob codegen recipe for external module builds [ Upstream commit 92dc59ab2a09097cdf249e0288ff9b69261761c6 ] When building with 'make M=drivers/gpu/drm/xe modules', kbuild invokes scripts/Makefile.build with obj=., causing $(obj) to expand to '.'. Make normalizes './xe_gen_wa_oob' to 'xe_gen_wa_oob' when constructing the $^ automatic variable (target name normalization), so the recipe command becomes just 'xe_gen_wa_oob ...' without any path prefix, and the shell cannot find the tool. Fix by replacing $^ with explicit $(obj)/xe_gen_wa_oob and $(src)/ references in both wa_oob recipe commands. In recipe strings, make does not apply target name normalization, so $(obj)/xe_gen_wa_oob correctly expands to './xe_gen_wa_oob' and the shell can execute it. This matches the pattern already used by other DRM drivers (e.g. radeon's mkregtable). Fixes: f037e0b78e6d ("drm/xe: add xe_device_wa infrastructure") Cc: Matt Atwood Cc: Matthew Brost Cc: Rodrigo Vivi Cc: intel-xe@lists.freedesktop.org Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260604074501.172129-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 3a11a63cc16660d514ff584e7551589655337e87) Signed-off-by: Matthew Brost Signed-off-by: Sasha Levin commit ac554ad943610031a25795d6ef71316f6164c136 Author: Guangshuo Li Date: Fri Jun 12 11:53:10 2026 +0800 drm/i915: clear CRTC color blob pointers after dropping refs [ Upstream commit 31f077088e0faae6be8377741f356dea1b94ba46 ] intel_crtc_put_color_blobs() drops the CRTC color blob references, but leaves the corresponding pointers unchanged. This can matter in intel_crtc_prepare_cleared_state(), which frees the old CRTC hw state before calling intel_dp_tunnel_atomic_clear_stream_bw(). The latter can fail while looking up the DP tunnel group state, for example with -EDEADLK. If that happens, the function returns without completing the cleared state preparation. The failed atomic state will then be cleared by the atomic core and intel_crtc_free_hw_state() can be called again for the same state, dropping the same blob references again. Clear the blob pointers after dropping the references so repeated cleanup of the same CRTC hw state is safe. Fixes: 77fcf58df15e ("drm/i915/dp_tunnel: Fix error handling when clearing stream BW in atomic state") Suggested-by: Imre Deak Signed-off-by: Guangshuo Li Reviewed-by: Imre Deak Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260612035310.3013066-1-lgs201920130244@gmail.com (cherry picked from commit d5005addb5f68e8a0edce249506757bdc9e3d8c8) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 9f171aa115ec76be02c76c5765cd2c865279e34a Author: Francesco Lavra Date: Tue Jun 16 13:44:29 2026 +0200 regcache: Do not overwrite error code when finalizing cache after error [ Upstream commit 9108f7fa493b4c88cbc09503e0c164244456bad5 ] During regcache initialization, if an error occurs in the cache_ops->populate callback, and if cache operations include an exit callback, the error code from populate() is overwritten with the return value from exit(). This hides the error condition from the caller of regcache_init(), and can cause NULL pointer dereferences when the regcache is later accessed. Fixes: 94a3a95f0315 ("regcache: Add ->populate() callback to separate from ->init()") Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20260616114429.1852456-1-flavra@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e06ad4356915f595c01ac7c7481c7c62c6d78c3f Author: Pengpeng Hou Date: Mon Jun 15 17:19:18 2026 +0800 gpio: mlxbf3: fail probe if gpiochip registration fails [ Upstream commit 0482862a90169f4daaba0ed31a85d8304bf51e04 ] mlxbf3_gpio_probe() logs a devm_gpiochip_add_data() failure but still returns success. That leaves the platform device bound even though the GPIO chip was not registered. Return the registration error so probe failure matches the missing gpiochip state. Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support") Signed-off-by: Pengpeng Hou Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260615091918.43333-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 99ab295d80255998dedaab3009a690b6f404fa9d Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 22:45:08 2026 -0300 perf cs-etm: Reject CPU IDs that would overflow signed comparison [ Upstream commit 542e88a4c6f7b6edd1326ce767d4cb3c2ea9d61d ] metadata[j][CS_ETM_CPU] is a u64 from perf.data, but the comparison with max_cpu casts it to (int). A crafted value like 0xFFFFFFFF becomes -1 after the cast, which compares less than max_cpu (0), so the queue array is never sized to accommodate it. When the value is later passed to cs_etm__get_queue(), it indexes queue_array with the original large value, causing an out-of-bounds access. Validate that CS_ETM_CPU fits in an int before using it in the signed comparison. Fixes: 57880a7966be510c ("perf: cs-etm: Allocate queues for all CPUs") Reported-by: sashiko-bot Cc: James Clark Cc: Adrian Hunter Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6d2aa8dfea1fc9f548a2f27710b2103c31bdfe31 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 21:23:35 2026 -0300 perf c2c: Free format list entries when releasing c2c hist entries [ Upstream commit 4a7500d772fe59653053db22ca83c9e2232b22e1 ] c2c_hists__init() calls hpp_list__parse() which allocates and registers format entries on hists->list. When c2c_he_free() destroys a c2c hist entry, it deletes the histogram entries and frees the hists container but never unregisters the format list entries, leaking them. Call perf_hpp__reset_output_field() before freeing the hists to properly unregister and free all format entries. Fixes: f485e33c4543ac31 ("perf c2c report: Add cacheline hists processing") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 62a11653847fbdee368f1b4e7d57870f2988e122 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 21:03:16 2026 -0300 perf bpf: Bounds-check array offsets in bpil_offs_to_addr() [ Upstream commit 033e85edfbf271f92979d2a39aeaf40f8472a795 ] bpil_offs_to_addr() converts offsets stored in perf.data's bpf_prog_info_linear structure into heap pointers by adding the offset to the data allocation base. The offsets come from untrusted file input and are not validated against data_len. If an offset exceeds data_len, the computed address points outside the allocated data buffer. Callers like synthesize_bpf_prog_name() then dereference prog_tags[sub_id] or func_info pointers, reading arbitrary heap memory. Add a bounds check: when an offset exceeds data_len, zero the field and skip the conversion. This prevents out-of-bounds pointer construction from crafted perf.data files. Reported-by: sashiko-bot Fixes: 6ac22d036f86c4e2 ("perf bpf: Pull in bpf_program__get_prog_info_linear()") Cc: Dave Marchevsky Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f9ec0eda83ea1cae928aa36d7dbdf4603bc6fa2f Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 21:02:25 2026 -0300 perf bpf: Reject oversized BPF metadata events that truncate header.size [ Upstream commit 2d6ea0875093da9033fcb62c09a9e2f1de49fe91 ] bpf_metadata_alloc() computes event_size from the number of BPF metadata variables and stores it in header.size, which is __u16. With 204 or more .rodata variables prefixed "bpf_metadata_", event_size exceeds 65535 and silently truncates. The truncated header.size causes synthesize_perf_record_bpf_metadata() to allocate a buffer sized by the truncated value, then memcpy the full event data into it — a heap buffer overflow. Add a check that event_size fits in __u16 before proceeding. BPF programs with that many metadata variables are exotic enough that silently dropping the metadata is acceptable. Reported-by: sashiko-bot Fixes: ab38e84ba9a80581 ("perf record: collect BPF metadata from existing BPF programs") Reviewed-by: Ian Rogers Cc: Blake Jones Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3fe6751a0697143857ca6d36cdafa2af9a1635b6 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 21:01:15 2026 -0300 perf bpf: Validate func_info_rec_size and sub_id in synthesize_bpf_prog_name() [ Upstream commit 10b3c3d63ecc17c6acb855bac5f40367f1115765 ] synthesize_bpf_prog_name() computes a pointer into the func_info array using sub_id * info->func_info_rec_size without validating either value. Both come from perf.data and are untrusted: - A func_info_rec_size smaller than sizeof(struct bpf_func_info) means the finfo pointer would reference a truncated entry, reading past it into adjacent data. - A sub_id >= nr_func_info computes an offset past the func_info buffer, causing an out-of-bounds read. Add bounds checks for both values before computing the pointer offset. When validation fails, fall through to the non-BTF name path instead of reading garbage. Reported-by: sashiko-bot Fixes: 7b612e291a5affb1 ("perf tools: Synthesize PERF_RECORD_* for loaded BPF programs") Cc: Song Liu Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit eaab676863cbe41a15e1db6c03cfc55b5c48e840 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 21:00:11 2026 -0300 perf sched: Replace (void*)1 sentinel with proper runtime allocation [ Upstream commit 500f5dd0a8b6f7bd174102587c7dff5a7d2fecbf ] map__findnew_thread() marks color-pid threads by storing (void*)1 as the thread private data via thread__set_priv(). This sentinel value causes two problems: 1. thread__get_runtime() returns (void*)1 as a struct thread_runtime pointer. Any field access (e.g. tr->shortname) dereferences address 1, which is an unmapped page — immediate segfault. 2. cmd_sched() registers free() as the thread priv destructor, so thread cleanup calls free((void*)1) — undefined behavior that corrupts the heap on many allocators. Fix by adding a 'color' flag to struct thread_runtime and allocating a real runtime struct for color-pid threads. thread__has_color() now checks the flag instead of relying on priv being non-NULL. Reported-by: sashiko-bot Fixes: 58a606149c60d5da ("perf sched: Avoid union type punning undefined behavior") Reviewed-by: Ian Rogers Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit dd8e455fd91ee7c875d6667384332f63059681ba Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 20:40:34 2026 -0300 perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items() [ Upstream commit cfafef390ca9c753b34c7e97b5abee4cab0ce270 ] hwmon_pmu__describe_items() checks 'if (fd > 0)' after openat(), which incorrectly rejects fd 0. While fd 0 is normally stdin, if stdin has been closed (common in daemon/service contexts), the kernel reuses fd 0 for the next open. With fd > 0, the sysfs file is not read and the fd is leaked. Change to 'if (fd >= 0)' to match the standard openat() error check. Reported-by: sashiko-bot Fixes: 53cc0b351ec99278 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Reviewed-by: Ian Rogers Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 97584371d5d8219ece84ed2602cde1e154f4cb73 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 20:34:38 2026 -0300 perf tools: Use snprintf() for root_dir path construction [ Upstream commit 7b0df6f4d498b1608afccfd6dffb264e6da91693 ] get_kernel_version() in machine.c and dso__load_guest_kernel_sym() in symbol.c use sprintf() to construct paths by prepending root_dir to "/proc/version" and "/proc/kallsyms" respectively. Both write into PATH_MAX stack buffers, but root_dir comes from --guestmount or KVM configuration and is not length-checked. A root_dir at or near PATH_MAX causes a stack buffer overflow. Switch to snprintf() with sizeof(path) to prevent overflow. Reported-by: sashiko-bot Fixes: a1645ce12adb6c9c ("perf: 'perf kvm' tool for monitoring guest performance from host") Cc: Zhang Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2367ebcd0d4bea2694ac7f6cb5efb80adc265233 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 20:16:02 2026 -0300 perf dso: Set error code when open() fails on uncompressed fallback path [ Upstream commit d2c6069d68ee9d53b05fe38bc2049cc4286fbb16 ] filename__decompress() has an early return for files that are not actually compressed, where it calls open() directly. When open() fails, the function returns -1 but never sets *err. The caller chain (decompress_kmodule → dso__decompress_kmodule_path → dso__get_filename) then reads *dso__load_errno(dso) to set errno, but that field was never populated, so errno gets a stale or zero value. With errno=0, __open_dso() computes fd = -errno = 0, which is non- negative, so callers treat fd 0 (stdin) as a valid DSO file descriptor. Set *err = errno when open() fails on the uncompressed path, matching the error handling on the compressed path at line 354. Reported-by: sashiko-bot Fixes: 8b42b7e5e8b5692b ("perf tools: Add is_compressed callback to compressions array") Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit c5dcbd5cf0079a7a1359516b832923446b79423e Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 19:33:48 2026 -0300 perf dso: Fix heap overflow in dso__get_filename() on decompressed path [ Upstream commit f973e52a99776fcc473488984828d1fce56d5382 ] dso__get_filename() allocates name with malloc(PATH_MAX), but the dso__filename_with_chroot() path replaces name with an asprintf'd exact-size string (e.g. 8 bytes for "/a/b.ko"). When the DSO needs decompression, dso__decompress_kmodule_path() writes the temp path ("/tmp/perf-kmod-XXXXXX", 22 bytes) into newpath, and strcpy(name, newpath) overflows the smaller allocation. Replace the strcpy with strdup(newpath) + free(name) so the buffer is always correctly sized for its content. Reported-by: sashiko-bot Fixes: 1d6b3c9ba756a513 ("perf tools: Decompress kernel module when reading DSO data") Reviewed-by: Ian Rogers Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit df77307da9da7e584966740966df606bd95f9386 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 19:32:22 2026 -0300 perf symbols: Break infinite loop on zero-filled notes in sysfs__read_build_id() [ Upstream commit 063c647b24f640657d6d9e2e90d620ea3ee19ae6 ] sysfs__read_build_id() iterates ELF note headers from sysfs files in a while(1) loop. If the file contains a zero-filled note header (both n_namesz and n_descsz are 0), the code computes n = namesz + descsz = 0 and calls read(fd, bf, 0). read() with count 0 returns 0, which matches the expected (ssize_t)n value, so the error check passes and the loop repeats — reading the same zero bytes and spinning forever. This can happen with corrupted or zero-padded sysfs pseudo-files. Add a check for n == 0 before the read, since no valid ELF note has both name and description of zero length. Reported-by: sashiko-bot Fixes: f1617b40596cb341 ("perf symbols: Record the build_ids of kernel modules too") Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6172d92a7f1542561964e2ec87cc7cb5a7c0bcbe Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 19:29:34 2026 -0300 perf symbols: Validate p_filesz before use in filename__read_build_id() [ Upstream commit 2a3716544359d4312c81b0fa909a13301186da17 ] filename__read_build_id() stores ELF p_filesz in a ssize_t variable. A crafted 32-bit ELF with p_filesz = 0xFFFFFFFF produces ssize_t value -1. The comparison `p_filesz > buf_size` evaluates false because signed -1 is less than any non-negative buf_size, so the realloc is skipped and buf remains NULL. The subsequent read(fd, NULL, -1) returns -1, which equals p_filesz, passing the error check. read_build_id() then dereferences the NULL buffer. Add an explicit check for p_filesz <= 0 before using the value, catching both zero-length and sign-wrapped negative sizes from crafted ELF files. Reported-by: sashiko-bot Fixes: ba0b7081f7a521d7 ("perf symbol-minimal: Fix ehdr reading in filename__read_build_id") Reviewed-by: Ian Rogers Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1ce03f1d990ec5b4adffebccf45715bb4b07b6b1 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 19:28:43 2026 -0300 perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz [ Upstream commit 081b387c7397498c583b1ba7c2fdaf4c6da6b538 ] filename__read_build_id() byte-swaps 32-bit ELF program headers on cross-endian files, but line 178 passes p_offset to bswap_32() instead of p_filesz: hdrs.phdr32[i].p_filesz = bswap_32(hdrs.phdr32[i].p_offset); This clobbers p_filesz with the already-swapped p_offset value. The 64-bit path on line 182 is correct and swaps p_filesz from p_filesz. The consequence is that the PT_NOTE segment read uses the wrong size, which can cause either a short read (missing the build-id) or an oversized read (reading past the segment into adjacent data). Fix by swapping the correct field. Reported-by: sashiko-bot Fixes: fef8f648bb47726d ("perf symbol: Fix use-after-free in filename__read_build_id") Reviewed-by: Ian Rogers Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a06241a08631f2247a8af0da90d75b55ca1fe4ac Author: Ian Rogers Date: Thu Jun 11 09:41:18 2026 -0700 perf maps: Add maps__mutate_mapping [ Upstream commit 75a4888b7029a1f98613aef91f517b2ee1f03d43 ] During kernel ELF symbol parsing (dso__process_kernel_symbol), proc kallsyms image loading (dso__load_kernel_sym, dso__load_guest_kernel_sym), and dynamic kernel memory map alignment updates (machine__update_kernel_mmap), the loader directly modifies live virtual address boundary keys fields on map objects. If these boundaries are mutated while the map pointer actively resides inside the parent maps cache array list (kmaps) outside of any lock closure, an unsafe concurrent window is exposed where parallel worker lookup threads (e.g., inside perf top) can mistakenly assume the cache remains sorted based on stale parameters, executing binary search queries (bsearch) across an unsorted range and triggering lookup failures. Fix this by introducing maps__mutate_mapping() that explicitly acquires the parent maps write semaphore lock, executes an incoming mutation callback block to perform the field updates under lock protection, and invalidates the sorted tracking flags prior to releasing the write lock. This guarantees synchronization invariants, closing the concurrent lookup race window. The adjacent module alignment pass inside machine__create_kernel_maps() is safely preserved as a high-performance lockless pass, as its invocation lifecycle bounds remain strictly single-threaded by contract during session initialization construction. To safely support this unconditional down_write write lock mutator without recursive read-to-write self-deadlock upgrades during lazy symbol loading, we introduce a public maps__load_maps() API. It copies map pointers under a brief read lock and force-loads all modules locklessly outside the lock. Callers (such as perf inject) must pre-load all kernel symbol maps up front at startup using maps__load_maps(), completely bypassing dynamic runtime mutations. Fixes: 39b12f781271 ("perf tools: Make it possible to read object code from vmlinux") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Tested-by: James Clark Cc: Adrian Hunter Cc: Gabriel Marin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit abbdd94e6a1065cd00e282836c8dd6cb810e0f86 Author: Pengpeng Hou Date: Mon Jun 15 13:58:50 2026 +0800 sparc: led: avoid trimming a newline from empty writes [ Upstream commit 7eb475e8a738ee6fd1260aa59ddccb610fdd4300 ] led_proc_write() duplicates up to LED_MAX_LENGTH bytes with memdup_user_nul() and then unconditionally inspects buf[count - 1] to strip a trailing newline. A zero-length write therefore reads one byte before the duplicated buffer. The previous version rejected empty writes, but empty input already falls through to the existing default case and turns the LED off like any other unrecognized string. Preserve that behavior and only skip the newline trim when there is no input byte to inspect. Fixes: ee1858d3122d ("[SPARC]: Add sun4m LED driver.") Suggested-by: Andreas Larsson Signed-off-by: Pengpeng Hou Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit f55b1ff899383a88a11bd3f1d2308343c8bfa538 Author: Karol Wachowski Date: Thu Jun 11 07:51:40 2026 +0200 accel/ivpu: fix HWS command queue leak on registration failure [ Upstream commit e7ab91e2bf01b024691d6ce488546533943e7a6b ] A command queue is considered valid and usable by the driver only when it has a doorbell ID assigned (db_id != 0), meaning both the FW cmdq creation and doorbell registration completed successfully. However, when either ivpu_register_db() or set_context_sched_properties() fails after ivpu_hws_cmdq_init() has already created the cmdq in FW, the command queue is left registered in FW while the driver treats it as uninitialized (db_id remains 0). On the next submission attempt the driver tries to register the same cmdq again, which fails because FW already has an entry for it. Fix by calling ivpu_jsm_hws_destroy_cmdq() on error paths to properly unwind FW state and allow subsequent registration attempts to succeed. Fixes: 465a3914b254 ("accel/ivpu: Add API for command queue create/destroy/submit") Reviewed-by: Andrzej Kacprowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260611055140.948684-1-karol.wachowski@linux.intel.com Signed-off-by: Sasha Levin commit 30521e7ec4d8309be4a1cb49a4d10d5ba5d83ac0 Author: John Johansen Date: Sun Jun 14 16:16:59 2026 -0700 apparmor: fix label can not be immediately before a declaration [ Upstream commit 1ed40bd525c00d22af666016af9aef7167f8085f ] Fix error reported by kernel test robot security/apparmor/policy.c:1381:2: error: a label can only be part of a statement and a declaration is not a statement All errors (new ones prefixed by >>): security/apparmor/policy.c: In function 'aa_replace_profiles': >> security/apparmor/policy.c:1381:2: error: a label can only be part of a statement and a declaration is not a statement ssize_t udata_sz = udata->size; ^~~~~ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606150525.npax8WiH-lkp@intel.com/ Fixes: 7b42f95813dc9 ("apparmor: fix potential UAF in aa_replace_profiles") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4b0c345217476ebaae8f7a13c7830d87bc5136ca Author: Adrian Hunter Date: Fri Jun 12 11:01:03 2026 +0300 i3c: master: Prevent reuse of dynamic address on device add failure [ Upstream commit b3ba8383da4d0cff15810e32ea785eceb0a80813 ] i3c_master_add_i3c_dev_locked() is called after a device has already been assigned a dynamic address. If the function fails, the address remains marked as free and may be reallocated to another device, leading to address conflicts on the bus. Ensure the address is not marked as free on failure, by updating the address slot state to prevent the address from being re-used. Emit an error message to inform of the failure. Opportunistically remove the !master check because it is impossible. Note, directly resetting the device's dynamic address is no longer an option, since Direct RSTDAA was deprecated from I3C starting from version 1.1 and v1.1 (or later) target devices are meant to NACK it. Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260612080107.11606-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 8f851cab401c28287d536b1347d76f6e219c0db6 Author: Adrian Hunter Date: Fri Jun 12 11:01:01 2026 +0300 i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev() [ Upstream commit 650716f23eac488c6696babdc7805f6a6b7427ad ] i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()). Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers. Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260612080107.11606-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 50eabb91d2de8ceda6fd8ed624719681794cf3cc Author: Adrian Hunter Date: Mon Jun 8 08:43:10 2026 +0300 i3c: master: Defer new-device registration out of DAA caller context [ Upstream commit 3f79dac3ea1c30516fcc791770af034387c7f917 ] Master drivers may invoke i3c_master_do_daa_ext() during resume to re-run Dynamic Address Assignment. As well as assigning addresses to any newly arrived devices, this restores the dynamic address of devices that lost it across system suspend, so it has to run as part of the controller's resume path. A side effect of i3c_master_do_daa_ext() today is that it also registers any newly discovered I3C devices with the driver model inline, via i3c_master_register_new_i3c_devs(). Doing that from the resume path is problematic: a hot-join-capable device may join the bus during this same DAA, and registering it immediately would push driver model work (probing, sysfs, etc.) into the controller's resume context, where the rest of the system is not yet fully resumed and the controller driver is still partway through its own resume sequence. Decouple discovery from registration: add a reg_work work item to struct i3c_master_controller and have i3c_master_do_daa_ext() queue it on master->wq (the freezable workqueue) instead of calling i3c_master_register_new_i3c_devs() directly. The worker performs the registration only when the controller is not shutting_down, and is cancelled alongside hj_work in i3c_master_shutdown(). Because wq is freezable, any newly observed devices end up being registered after the system has finished resuming. i3c_master_register() also routes its initial post-bus-init registration through reg_work, using flush_work() to keep probe-time behavior synchronous. This keeps a single registration code path and ensures the worker is the only writer of desc->dev. Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260608054312.10604-7-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit fef9bdaa0df025a26d1b65be93caaf39d7631700 Author: Adrian Hunter Date: Mon Jun 8 08:43:08 2026 +0300 i3c: master: Ensure Hot-Join operations are stopped on shutdown [ Upstream commit 8323e783dc3904839e64cb08cfcc7571ef9212c4 ] System shutdown invokes each device's bus shutdown callback to quiesce hardware, but the I3C bus type does not currently implement one. As a result, on shutdown the controller's Hot-Join work and any in-flight i3c_master_do_daa() can keep running (or be newly triggered) while the rest of the system is being torn down. A similar window exists at i3c_master_unregister() time: cancel_work_sync() on hj_work prevents queued work from completing, but does not stop a fresh Hot-Join IBI from re-queueing the worker, nor a concurrent sysfs writer from toggling Hot-Join via i3c_set_hotjoin(). Introduce a single "shutting down" gate in the I3C core, set under the bus maintenance lock so it is observed by any in-progress DAA path before pending work is cancelled. Install an i3c_bus_type shutdown callback that engages this gate for master devices during system shutdown, and use the same gate in i3c_master_unregister() so both paths get identical guarantees. Once the gate is engaged, the Hot-Join worker, i3c_master_do_daa_ext() and i3c_set_hotjoin() all bail out cleanly, so Hot-Join IBIs that race with shutdown become no-ops, direct DAA callers see -ENODEV, and sysfs writers can no longer re-enable Hot-Join through ops->enable_hotjoin() while the controller is going away. No functional change for the steady-state runtime path; the new checks only take effect once the controller has been marked as shutting down. Note, this patch depends on patch "i3c: master: Consolidate Hot-Join DAA work in the core". Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260608054312.10604-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: 3f79dac3ea1c ("i3c: master: Defer new-device registration out of DAA caller context") Signed-off-by: Sasha Levin commit 08b33dfd457bad48de9c65d2e8e059a81a40b089 Author: Adrian Hunter Date: Mon Jun 8 08:43:07 2026 +0300 i3c: master: Consolidate Hot-Join DAA work in the core [ Upstream commit 828c6130235db8144f4810b329b61390dc82719b ] Three master drivers (dw-i3c-master, i3c-master-cdns, svc-i3c-master) each carry an essentially identical Hot-Join handler: a struct work_struct embedded in their private state, a work function that just calls i3c_master_do_daa() on the embedded i3c_master_controller, plus matching INIT_WORK()/cancel_work_sync() boilerplate in probe/remove (and shutdown for dw-i3c). The IBI/ISR paths then queue that work onto master->wq, which already lives in the core. Move this pattern into the I3C core: - Add struct work_struct hj_work to struct i3c_master_controller and initialise it in i3c_master_register() with a core-provided handler i3c_master_hj_work_fn() that performs i3c_master_do_daa(). - Cancel the work in i3c_master_unregister() so all controllers get correct teardown ordering against the workqueue for free. - Export i3c_master_queue_hotjoin() as the single entry point drivers call from their Hot-Join IBI handler. Convert the three existing users to the new API: drop their private hj_work fields, work functions, INIT_WORK() and cancel_work_sync() calls, and replace the queue_work(master->wq, &drv->hj_work) call sites with i3c_master_queue_hotjoin(&drv->base). The dw-i3c shutdown path still needs to flush pending Hot-Join work before tearing down the hardware, so it is updated to cancel master->base.hj_work directly. No functional change intended: the work is still queued on the same master->wq, runs the same i3c_master_do_daa(), and is cancelled at controller teardown. Future Hot-Join improvements now only need to be made in one place. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260608054312.10604-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: 3f79dac3ea1c ("i3c: master: Defer new-device registration out of DAA caller context") Signed-off-by: Sasha Levin commit 21cf9175b3700523d2920dc369c5d09abc4f6b98 Author: Adrian Hunter Date: Mon Jun 8 08:43:06 2026 +0300 i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock [ Upstream commit 5b130aadc36b6a935b90937dcd67b8ed4ba57831 ] i3c_set_hotjoin() dispatches the controller's enable_hotjoin() or disable_hotjoin() op and updates master->hotjoin under i3c_bus_normaluse_lock(). That lock is a read-side acquisition of bus->lock (down_read()), so it does not exclude concurrent callers. The hotjoin sysfs attribute can be opened multiple times, and writes through different opens are not serialized. Two concurrent writers to "hotjoin" can therefore race in i3c_set_hotjoin(), with the controller op and the master->hotjoin store from one call interleaving with the other. The hardware enable/disable state and the value reported by hotjoin_show() can end up out of sync. Take i3c_bus_maintenance_lock() instead. Toggling Hot Join enable changes bus state and is conceptually a maintenance operation, so the write-side acquisition of bus->lock is the appropriate lock and serializes concurrent callers against each other and against other maintenance operations. Fixes: 317bacf960a48 ("i3c: master: add enable(disable) hot join in sys entry") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260608054312.10604-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit af6df5d506078fe78caf73d597bea68b3774f189 Author: Adrian Hunter Date: Mon Jun 8 08:43:05 2026 +0300 i3c: master: Make hot-join workqueue freezable to block hot-join during suspend [ Upstream commit 527756cb9ebb277dca12fff00af9fbb3b9ec8cc8 ] The I3C master workqueue (master->wq) is used to defer work that needs thread context and the bus maintenance lock, most notably Hot Join processing (which calls i3c_master_do_daa() to assign dynamic addresses to newly joined devices). Currently the workqueue keeps running across system suspend, which can race with the suspend path: - do_daa() may execute after the controller has been suspended, issuing bus transactions on a powered-down or otherwise unusable controller. - New I3C devices can be enumerated and added to the bus mid-suspend, registering driver model objects at a point where the I3C subsystem and its consumers are not prepared to handle them. Mark the workqueue WQ_FREEZABLE so its workers are frozen for the duration of system suspend/hibernate and resumed afterwards. This naturally defers any pending or newly queued Hot Join work until the system (and the controller) is fully resumed, closing both races without adding explicit suspend/resume synchronization in the master drivers. Update the kerneldoc for struct i3c_master_controller::wq to reflect that the workqueue is freezable. Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260608054312.10604-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 88116f41086a5e09c21c95b12d37fdc1380bc580 Author: Adrian Hunter Date: Wed Jun 3 12:07:39 2026 +0300 i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring [ Upstream commit 093eb8e73c90aa0c8cfb0421aa85bd70c23488be ] The MIPI I3C HCI specification does not require the DMA ring RUN bit (RUN_STOP) to be cleared when issuing an ABORT. That allows the DMA ring to continue to receive IBIs, although an IBI is anyway not lost because it can be received once the ring restarts if the I3C device has not given up. Note, currently ABORT is only used on a timeout error path so the change has very little effect in practice. In the more common case of a transfer error, the ring (bundle) operation is halted by the controller anyway. Adjust the RING_CONTROL handling to set ABORT without clearing RUN_STOP, bringing the driver into alignment with the specification. Fixes: b795e68bf3073 ("i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260603090754.16252-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 49a230c2aea4c1dd3217293dc11ad5e6f0a444d6 Author: Adrian Hunter Date: Wed Jun 3 12:07:38 2026 +0300 i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to software reset [ Upstream commit 57e181af13de36571380ef3cc74000559826fa9b ] Software reset was introduced as a fallback if bus disable failed. The change was made in 2 places: the cleanup path and the suspend path. For the cleanup path (i3c_hci_bus_cleanup()), after software reset the function continues to do cleanup for the current I/O mode. For the suspend path (i3c_hci_rpm_suspend()), after software reset the function returns early. However software reset does not reset any Ring Headers in the Host Controller, so returning early is not the right thing to do. Instead, continue to call suspend for the current I/O mode, which for DMA mode will reset any Ring Headers. Note, although Ring Headers should not be active at this stage, performing this reset follows the procedure defined by the specification and keeps the suspend path consistent with the cleanup path. Note also, i3c_hci_sync_irq_inactive() is still called via the PIO and DMA hci->io->suspend() callbacks. Always return 0 because the device is quiesced as much as possible and returning a negative error code would unnecessarily prevent system suspend. Fixes: 9a258d1336f7 ("i3c: mipi-i3c-hci: Fallback to software reset when bus disable fails") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260603090754.16252-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 4238195ed98939a9e7623b8705a29242ff15e887 Author: Eduardo Vasconcelos Date: Thu May 21 12:13:06 2026 -0300 apparmor: Fix inverted comparison in cache_hold_inc() [ Upstream commit 5112ed5258b8d5e0769ae7d2bf9c9dea14c59703 ] cache_hold_inc() prevents the per-CPU cache hold counter from rising above MAX_HOLD_COUNT, but the comparison is inverted (> MAX_HOLD_COUNT instead of <), so the counter never rises above 0. This breaks the cache mechanism because since the hold counter is always 0, the global pool is always attempted first before falling back to the local cache. The decrement also never occurs, thus the hold counter is effectively dead. Fix by changing > to < in cache_hold_inc(). Fixes: 0b6a6b72b329 ("apparmor: document the buffer hold, add an overflow guard") Signed-off-by: Eduardo Vasconcelos Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit a5c79d44ef19203bd7cf6f3de8ff088112ebff95 Author: Maciek Borzecki Date: Fri May 8 10:30:16 2026 +0200 apparmor: fix uninitialised pointer passed to audit_log_untrustedstring() [ Upstream commit bcd1b34c21748531a3febaf7440632b89d8deab7 ] Commit 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") intrdouced a small bug, where path_name() may pass a potentially uninitialized *name to aa_audit_file() if the path->dentry had been replaced with aa_null.dentry earlier on. This can lead to page fault like one observed on 7.0.2 openSUSE Tumbleweed kernel: [51692.242756] [ T24690] BUG: unable to handle page fault for address: 0000000f00000003 [51692.242762] [ T24690] #PF: supervisor read access in kernel mode [51692.242763] [ T24690] #PF: error_code(0x0000) - not-present page [51692.242765] [ T24690] PGD 0 P4D 0 [51692.242768] [ T24690] Oops: Oops: 0000 [#1] SMP NOPTI [51692.242772] [ T24690] CPU: 3 UID: 1020 PID: 24690 Comm: snap-confine Tainted: G O 7.0.2-1-default #1 PREEMPT(full) openSUSE Tumbleweed ab90b4c9940707f9cafa19bdad80b2cec52dbe51 [51692.242775] [ T24690] Tainted: [O]=OOT_MODULE [51692.242777] [ T24690] Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP05, BIOS 03.18 01/08/2026 [51692.242778] [ T24690] RIP: 0010:strlen+0x4/0x30 [51692.242783] [ T24690] Code: f7 75 ec 31 c0 e9 17 9f 00 ff 48 89 f8 e9 0f 9f 00 ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 18 48 89 f8 0f 1f 40 00 48 83 c0 01 80 38 00 75 f7 48 [51692.242785] [ T24690] RSP: 0018:ffffd015eb1e3608 EFLAGS: 00010282 [51692.242787] [ T24690] RAX: 0000000000000000 RBX: ffff89796198a360 RCX: 0000000000000000 [51692.242788] [ T24690] RDX: 00000000000000d1 RSI: 0000000f00000003 RDI: 0000000f00000003 [51692.242790] [ T24690] RBP: ffffffffb7ede090 R08: 00000000000005f5 R09: 0000000000000000 [51692.242791] [ T24690] R10: 0000000000000000 R11: 0000000000000000 R12: ffffd015eb1e3700 [51692.242792] [ T24690] R13: ffff8977a22bc380 R14: ffffffffb7ec5190 R15: ffff8977a0c8aa80 [51692.242794] [ T24690] FS: 0000000000000000(0000) GS:ffff897f640d8000(0000) knlGS:0000000000000000 [51692.242796] [ T24690] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [51692.242797] [ T24690] CR2: 0000000f00000003 CR3: 00000006ad15f000 CR4: 0000000000f50ef0 [51692.242799] [ T24690] PKRU: 55555554 [51692.242800] [ T24690] Call Trace: [51692.242802] [ T24690] [51692.242804] [ T24690] audit_log_untrustedstring+0x1d/0x40 [51692.242811] [ T24690] common_lsm_audit+0x71/0x1d0 [51692.242816] [ T24690] aa_audit+0x5a/0x170 [51692.242819] [ T24690] aa_audit_file+0x18a/0x1b0 [51692.242825] [ T24690] path_name+0xd2/0x100 [51692.242829] [ T24690] profile_path_perm.part.0+0x58/0xb0 [51692.242832] [ T24690] aa_path_perm+0xef/0x150 [51692.242837] [ T24690] apparmor_file_open+0x153/0x2e0 [51692.242840] [ T24690] security_file_open+0x46/0xd0 [51692.242844] [ T24690] do_dentry_open+0xe9/0x4d0 [51692.242848] [ T24690] vfs_open+0x30/0x100 While here, initialise variables which are passed down to path_name(). Fixes: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Maciek Borzecki Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 3f172fbbe3570e5d24c56f3a9308649f8c4a4a95 Author: Georgia Garcia Date: Thu May 28 16:04:12 2026 -0300 apparmor: don't audit files pointing to aa_null.dentry [ Upstream commit add2b70038bea194bcdef8a680f9153ee7f93ac0 ] In commit 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") there was a change to not audit files pointing to aa_null.dentry because they provide no value, but setting the error variable instead of returning -EACCES was still causing them to be audited. Fixes: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Acked-by: David Disseldorp Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 859ba6c7fc6e743422b055f40dd76c464ad7942c Author: Zygmunt Krynicki Date: Tue May 5 05:40:53 2026 +0200 apparmor: put secmark label after secid lookup [ Upstream commit 340372688bb87da45ff8d4e2f82ccfd1b64c65ff ] apparmor_secmark_init() parses a configured secmark label to obtain its secid. aa_label_strn_parse() returns a refcounted label, but the success path kept that reference after copying the secid. Fixes: ab9f2115081a ("apparmor: Allow filtering based on secmark policy") Signed-off-by: Zygmunt Krynicki Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit b1abb53407370a74a3d375f68a251e06b38d4a3d Author: Zygmunt Krynicki Date: Sat May 2 13:37:14 2026 +0200 apparmor: aa_getprocattr free procattr leak on format failure [ Upstream commit fea23bf73f0cae8ccb1d0684e4a3003874771f41 ] aa_getprocattr() allocates the output string before rendering the label into it. If the second aa_label_snxprint() call fails, the function returned without freeing that allocation. Free and clear the output pointer on the uncommon formatting failure path before dropping the namespace reference. Fixes: 76a1d263aba3 ("apparmor: switch getprocattr to using label_print fns()") Reviewed-by: Tyler Hicks Reviewed-by: Ryan Lee Signed-off-by: Zygmunt Krynicki Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit de91788aa6b88bd71de36c7ac453383991ef54c5 Author: John Johansen Date: Wed May 6 01:17:38 2026 -0700 apparmor: remove unnecessary goto and associated label [ Upstream commit e27bfb2ae9ad8522aea82d435fd6d73cccee7e17 ] There is no need for a goto a label immediately following the conditional block when the jump is the last statement in the block. Fixes: 7306c41672487 ("apparmor: release exe file resources on path failure") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 393809a05cfb60309ad63ee09138db8296d6b97e Author: Zygmunt Krynicki Date: Mon May 4 13:13:24 2026 +0200 apparmor: release exe file resources on path failure [ Upstream commit 7306c41672487a6c28430714be063bc6942c28f2 ] get_current_exe_path() takes both an exe_file reference and a path reference before resolving the path name. If aa_path_name() failed, it returned immediately and leaked both references. Route the failure through the common cleanup path so fput() and path_put() always run after the references are acquired. Fixes: 8d34e16f7f2b ("apparmor: userns: Add support for execpath in userns") Reviewed-by: Ryan Lee Signed-off-by: Zygmunt Krynicki Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 106e909e12baf059538f0b0f1a59f87781d25b3c Author: Zygmunt Krynicki Date: Mon May 4 08:32:37 2026 +0200 apparmor: fail policy unpack on accept2 allocation failure [ Upstream commit 45cf568241048e560a81aa2053f06a62069f5640 ] unpack_pdb() may need to allocate a missing ACCEPT2 table for older policy data. If that allocation failed, it set an error message but jumped to the success path, returning a policydb with the required table missing. Return -ENOMEM through the normal failure path when the ACCEPT2 allocation fails. Remove the now-unused out label. Fixes: 2e12c5f06017 ("apparmor: add additional flags to extended permission.") Reviewed-by: Ryan Lee Signed-off-by: Zygmunt Krynicki Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit bd30d91f9f22b184d613b22fe37a470234b032b0 Author: Hongling Zeng Date: Sun May 3 12:12:43 2026 +0800 apparmor: Fix return in ns_mkdir_op [ Upstream commit b7a2b49bba4e5994a476c49d662b796818079e5e ] Return NULL instead of passing to ERR_PTR while error is zero. Fixes smatch warning: - security/apparmor/apparmorfs.c:1846 ns_mkdir_op() warn: passing zero to 'ERR_PTR' Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Reviewed-by: Ryan Lee Signed-off-by: Hongling Zeng Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 2118a9f7a7edf62eec83c21623593ffbbe375eaf Author: Georgia Garcia Date: Thu Jan 29 15:39:42 2026 -0300 apparmor: remove or add symlinks to rawdata according to export_binary [ Upstream commit 59fe6fbc4cd45582bc8893de0a382a36562317b3 ] When the export_binary parameter is set, then rawdata is available and there should be a symbolic link for the rawdata in the profile directory in apparmorfs. If the parameter is unset, then the symlinks should not exist. The issue arises when changing the value of export_binary on runtime and replacing profiles. If export_binary was set when the profile was originally loaded, then changed to 0 and the profile was reloaded, then the symbolic links would still exist but would return ENOENT because the rawdata no longer exists. On the opposite side, if export_binary was unset when the profile was originally loaded, then changed to 1 and the profile was reloaded, then the symbolic links would not exist, even though the rawdata does. Fixes: d61c57fde8191 ("apparmor: make export of raw binary profile to userspace optional") Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 73d86ca950b80cd39ca948e2c518d135bf2308c8 Author: Georgia Garcia Date: Wed May 6 16:02:11 2026 -0300 apparmor: fix NULL pointer dereference in unpack_pdb [ Upstream commit 7681ca43d2b1c776e62fe77e3167835fb1ab8319 ] pdb->dfa could be NULL if unpack_dfa fails, causing a NULL pointer dereference. Fixes: 2e12c5f06017 ("apparmor: add additional flags to extended permission.") Signed-off-by: Georgia Garcia Signed-off-by: Manuel Diewald Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit dd5f1202f45a2dbe2c7dd10093f5c6bb2d8ac5bb Author: Maxime Bélair Date: Wed Feb 18 10:27:34 2026 +0100 apparmor: fix potential UAF in aa_replace_profiles [ Upstream commit 7b42f95813dc9ceb6bda35afcf914630909a19f9 ] The function aa_replace_profiles was accessing udata->size after calling aa_put_loaddata(udata), causing a potential UAF. Fixed this by saving the size to a local variable before dropping the reference. Fixes: 5ac8c355ae001 ("apparmor: allow introspecting the loaded policy pre internal transform") Reviewed-by: Georgia Garcia Signed-off-by: Maxime Bélair Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 67ee65ec1a3eebdde76ccaa664d20dcf5b125a2f Author: Ryan Lee Date: Fri Feb 13 11:29:38 2026 -0800 apparmor: grab ns lock and refresh when looking up changehat child profiles [ Upstream commit 32e92764d6f8d251c1bca62be33793287b453a81 ] There was a race condition involving change_hat and profile replacement in which replacement of the parent profile during a changehat operation could result in the list of children becoming empty and the changehat operation failing. To prevent this: - grab the namespace lock until we've built the hat transition, and - use aa_get_newest_profile to avoid using stale profile objects. Link: https://bugs.launchpad.net/bugs/2139664 Fixes: 89dbf1962aa63 ("apparmor: move change_hat mediation to using labels") Reviewed-by: Georgia Garcia Signed-off-by: Ryan Lee Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4a2c4f2b45dca0fc791e5d56b91df2fdd3b447b8 Author: John Johansen Date: Sun Mar 1 12:24:06 2026 -0800 apparmor: fix rawdata_f_data implicit flex array [ Upstream commit ad213bbbc0e3e270ce7df2d9d80d4ce3826993d7 ] rawdata_f_data has a blob of data that is allocated at its end but not explicitly declared. Makes sure it is correctly declared as a flex_rray. Fixes: 63c16c3a76085 ("apparmor: Initial implementation of raw policy blob compression") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 6d91479174240f39e9edea250d95fa08c678a207 Author: Zygmunt Krynicki Date: Sat May 2 13:21:33 2026 +0200 apparmor: aa_label_alloc use aa_label_free on alloc failure [ Upstream commit 654fe7505dc6889724d4094fa64f89991afabfc3 ] aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed. Fixes: f1bd904175e81 ("apparmor: add the base fns() for domain labels") Signed-off-by: Zygmunt Krynicki Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit ec926b2a351eeeb31e6c9aee02e0c32f94b5588f Author: Ruoyu Wang Date: Mon Jun 8 14:36:31 2026 +0800 apparmor: check label build before no_new_privs test [ Upstream commit a58cafd38b46fb1a2220e2fbbcfe291ea75fa147 ] aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label. Fixes: e00b02bb6ac2a ("apparmor: move change_profile mediation to using labels") Signed-off-by: Ruoyu Wang Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 25b262492539f020efa0f1d1d3d2c3bc6c4df8fa Author: Andrew Morton Date: Wed Jun 3 13:30:46 2026 -0700 security/apparmor/apparmorfs.c: conditionally compile get_loaddata_common_ref() [ Upstream commit d62d9bfe050f44f772d05a32079dba3e3523ab2a ] Some config did this: security/apparmor/apparmorfs.c:177:28: warning: 'get_loaddata_common_ref' defined but not used [-Wunused-function] 177 | static struct aa_loaddata *get_loaddata_common_ref(struct aa_common_ref *ref) get_loaddata_common_ref() is only used if CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y. (Or of course move the function into that block if maintainers perfer) Fixes: 8e135b8aee5a0 ("apparmor: fix race between freeing data and fs accessing it") Cc: John Johansen Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Signed-off-by: Andrew Morton Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit b8642f1478982a97ca2eb59f70f631a9de42ae11 Author: John Johansen Date: Fri Oct 24 12:59:51 2025 -0700 apparmor: fix refcount leak when updating the sk_ctx [ Upstream commit 6d25e7b47616cb2db43351210929c8f19dc305a3 ] Currently update_sk_ctx() transfers the plabel reference, unfortunately it is also unconditionally put in the caller. Ideally we would make the caller conditionally put the reference based on whether it was transferred but for now just fix the bug by getting a reference. Fixes: 88fec3526e841 ("apparmor: make sure unix socket labeling is correctly updated.") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit d680472db98823d90fc91362910901e468269318 Author: John Johansen Date: Fri Oct 24 12:25:38 2025 -0700 apparmor: fix race in unix socket mediation when peer_path is used [ Upstream commit b1aea2c1960771a276d7e68c7424168eccd0c3da ] The holding a reference to the peer_sk is not enough to ensure access to the peer sk path. Accessing the path outside of the state lock allows for a race with unix_release_sock(). Fix this by taking the state lock and getting a reference to the path under lock. Ideally for connected sockets we would cache this information so we don't have to take the lock here. But for now just fix the race. Fixes: bc6e5f6933b8e ("apparmor: Remove use of the double lock") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit ec95dec9ae2c30e99bbb3e59950d7493021961ec Author: John Johansen Date: Wed Oct 22 23:46:19 2025 -0700 apparmor: fix shadowing of plabel that prevents cache from being updated [ Upstream commit 4483efe4f21510b30c24bc97d9fd0e8feab94125 ] Unfortunately the plabel was being shadowed by an unused local var. This didn't affect the mediation check but did cauase the cache to not correctly be updated resulting in extra mediation checks. Fixes: 88fec3526e841 ("apparmor: make sure unix socket labeling is correctly updated.") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 3691a82be2095abaf3326a1cbf7b25858a1d959c Author: Yuanhe Shu Date: Thu Jun 11 10:59:01 2026 +0800 Revert "PCI/MSI: Unmap MSI-X region on error" [ Upstream commit f64e03da0d83cb173743888bff4a7e61476a8fc2 ] This reverts commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202. Commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") added an iounmap(dev->msix_base) on the error path of msix_capability_init() to release the MSI-X region when msix_setup_interrupts() fails. When msix_setup_interrupts() fails, the call chain is: msix_setup_interrupts() -> __msix_setup_interrupts() struct pci_dev *dev __free(free_msi_irqs) = __dev; ... return ret; // __free cleanup fires on error The __free(free_msi_irqs) cleanup calls pci_free_msi_irqs(), which already handles the unmap: void pci_free_msi_irqs(struct pci_dev *dev) { pci_msi_teardown_msi_irqs(dev); if (dev->msix_base) { iounmap(dev->msix_base); // already unmapped here dev->msix_base = NULL; // and set to NULL } } So dev->msix_base is unmapped and set to NULL before msix_setup_interrupts() returns to msix_capability_init(). The "goto out_unmap" introduced by commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") then calls iounmap() a second time on a NULL pointer. This was reproduced on Intel Emerald Rapids (192 CPUs) while running tools/testing/selftests/kexec/test_kexec_jump.sh: WARNING: CPU#44 at iounmap+0x2a/0xe0 RIP: 0010:iounmap+0x2a/0xe0 RDI: 0000000000000000 Call Trace: msix_capability_init+0x317/0x3f0 __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme] nvme_reset_work+0x151/0x340 [nvme] ... RDI=0 confirms iounmap() is called with NULL. Restore the original "goto out_disable" and leave the unmap to the existing __free(free_msi_irqs) cleanup. Fixes: 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") Reported-by: Guenter Roeck Signed-off-by: Yuanhe Shu Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20260610194406.GA380991@bhelgaas/ Link: https://patch.msgid.link/20260611025901.1105209-1-xiangzao@linux.alibaba.com Closes: https://lore.kernel.org/all/4fc6208d-513b-4f41-a13a-4a0829ab50ad@roeck-us.net/ Signed-off-by: Sasha Levin commit 91fbf0de91bc2a9178603a222e39829a1fad3ee6 Author: Randy Dunlap Date: Sun Apr 26 16:27:05 2026 -0700 Documentation: ABI: sysfs-class-reboot-mode-reboot_modes: fix doc warnings [ Upstream commit a888754e51e915731c8974c4d6d62709facb35d3 ] Repair the docs build warnings in this file by unindenting the description, adding blank lines, and using `` to quote *arg. WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils] Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils] Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: WARNING: Inline emphasis start-string without end-string. [docutils] Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils] Fixes: d3da03025e6d ("Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes") Signed-off-by: Randy Dunlap Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260426232705.422938-1-rdunlap@infradead.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 375e1defdeb86ce6ea3af2d7bd106c98cd5e2e27 Author: Thomas Weißschuh Date: Mon May 25 10:36:21 2026 +0200 sparc: Avoid -Wunused-but-set-parameter in clear_user_page() [ Upstream commit 9bc0bd9617964804dc02e6ee2413af42c4a50d6b ] The loop in clear_user_pages() iterates over all pages and calls clear_user_page() for each of them. During the loop "vaddr" is modified. However on sparc clear_user() is a macro which does not use "vaddr". The compiler sees a variable which is modified but never used and emits a warning for that: include/linux/highmem.h: In function 'clear_user_pages': include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=] static inline void clear_user_pages(void *addr, unsigned long vaddr, Other architectures use an inline function for clear_user_page() which avoids the warning. This is not possible on sparc, as sparc_flush_page_to_ram() is not yet declared where clear_user_page() is defined. Including cacheflush_32.h will trigger recursive and lots of other issues. So hide the warning with a cast to (void) instead. While we are here, do the same for copy_user_page(). Fixes: 62a9f5a85b98 ("mm: introduce clear_pages() and clear_user_pages()") Signed-off-by: Thomas Weißschuh Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 63a30015199912bd5055bead8001b1ae68a67cdb Author: Dong Chenchen Date: Tue Jun 9 17:21:17 2026 +0800 xfrm: Fix dev use-after-free in xfrm async resumption [ Upstream commit 8045c0df98d4f14c54e5cb875f1c9c0ce89fe4ff ] xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races. Fixes: 1c428b038400 ("xfrm: hold dev ref until after transport_finish NF_HOOK") Reported-by: Xu Chunxiao Signed-off-by: Dong Chenchen Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 855870e8c59b97fd424e8fa3543c9e289bb48fac Author: Shuvam Pandey Date: Mon May 18 22:44:17 2026 +0545 PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when no RAS DES capability [ Upstream commit 26b67fa10ef84ea667942491b50e6261a45f098d ] dwc_pcie_rasdes_debugfs_init() returns success when the controller has no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The common debugfs teardown path still calls dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info unconditionally. Return early when no RAS DES state was allocated. In that case no RAS DES mutex was initialized, so there is nothing to destroy. Fixes: 4fbfa17f9a07 ("PCI: dwc: Add debugfs based Silicon Debug support for DWC") Signed-off-by: Shuvam Pandey [mani: reworded subject] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/0f97352506d8d813f70f441de4d63fcd5b7d1c3e.1779123847.git.shuvampandey1@gmail.com Signed-off-by: Sasha Levin commit 9720527646720e90a19df55f6c441f92a4830bf1 Author: Felix Gu Date: Fri Jun 5 19:57:20 2026 +0800 phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing pm_runtime_disable() on probe error path [ Upstream commit 799e7cf2f0b50b34660b5ffce0f7d8dec376a0d5 ] If mixel_lvds_phy_reset() fails in probe after pm_runtime_enable(), the function returns directly without calling pm_runtime_disable(), leaving runtime PM permanently enabled for the device. Fix this by using devm_pm_runtime_enable() so that cleanup is automatic on any probe failure or driver unbind. This also allows removing the manual err label and the .remove callback. Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support") Acked-by: Liu Ying Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260605-lvds-v2-1-3ce7539d1104@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d31244d1732e12a97dd83abe1ad19f5b4f24a5eb Author: Felix Gu Date: Tue Jun 9 22:48:50 2026 +0800 phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset [ Upstream commit b28ec8ce03d8f9a0f7a9ec84f1ed9b5a6f393791 ] The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get() with pm_runtime_put(). The asynchronous variant queues a work item to handle the idle check and potential suspend, which can be cancelled by a subsequent pm_runtime_disable() call if probe fails after the reset. Switch to pm_runtime_put_sync() to run the idle check and suspend synchronously. Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support") Reported-by: sashiko Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 393f0bb615459fab64c845398fbb43f3594469f8 Author: Manivannan Sadhasivam Date: Thu May 21 17:19:49 2026 +0000 PCI: mediatek: Use actual physical address instead of virt_to_phys() [ Upstream commit ebc1d9906894703286d12306a6f242d90cfb49e8 ] The driver previously used virt_to_phys() on the ioremapped register base (port->base) to compute the MSI message address. Using virt_to_phys() on an IO mapped address is incorrect because it expects a kernel virtual address. To fix it, store the physical start of the I/O register region in mtk_pcie_port->phys_base and use it to build the MSI address. This replaces the incorrect virt_to_phys() usage and ensures MSI addresses are generated correctly. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Tested-by: Caleb James DeLisle Link: https://patch.msgid.link/20260521171951.1495781-2-cjd@cjdns.fr Signed-off-by: Sasha Levin commit f66b4e65c4cc5a98d873c74c1e33c5bc2bb88450 Author: Konrad Dybcio Date: Wed Jun 10 11:45:12 2026 +0200 dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa [ Upstream commit b3ee497970c63cea37976aeaa84bac39611fe0eb ] Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation. The PHY is however physically laid out as if it were to, since there are two separate ports (A/B). Split out a new if-then block to un-require the bifurcation register handle to squash this warning: purwa-iot-evk.dtb: phy@1bd4000 (qcom,x1p42100-qmp-gen4x4-pcie-phy): 'qcom,4ln-config-sel' is a required property Fixes: 2e1ffd4c1805 ("dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY") Reported-by: Rob Herring Closes: https://lore.kernel.org/linux-arm-msm/176857775469.1631885.16133311938753588148.robh@kernel.org/ Signed-off-by: Konrad Dybcio Acked-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260610-topic-purwa_phy_shutup_warning-v2-1-951c1fbfe9b2@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e30fa32cd0789de847f4965793d944231c6f739e Author: Inochi Amaoto Date: Mon May 11 14:38:16 2026 +0800 dt-bindings: dma: snps,dw-axi-dmac: Add fallback compatible for CV1800B [ Upstream commit 7524fe142b5a772f8421aeee2132cf7e21a00103 ] The previous version of the binding change only add compatible string without adding the fallback compatible, this breaks backward compatibility. Add the needed fallback compatible to fix this. Fixes: be3e2a0419c6 ("dt-bindings: dma: snps,dw-axi-dmac: Add CV1800B compatible") Signed-off-by: Inochi Amaoto Acked-by: Conor Dooley Link: https://patch.msgid.link/20260511063818.463877-2-inochiama@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 65a406f5bbd9275cdbf614a8c0d5e6676d3aa238 Author: Arnaldo Carvalho de Melo Date: Wed Jun 10 16:09:45 2026 -0300 perf symbols: Add bounds checks to read_build_id() note iteration in minimal build [ Upstream commit 52e582e316c48c53bb3082c29f7862ebc554087e ] symbol-minimal.c's read_build_id() iterates ELF notes with the same pattern as symbol-elf.c's elf_read_build_id(): pointer arithmetic driven by n_namesz and n_descsz from 32-bit note header fields, without validating that the name and desc fit within the note section data. A malformed ELF file with oversized note sizes causes out-of-bounds reads past the section data buffer. Add the same bounds check as the libelf path: validate namesz and descsz individually against remaining data before advancing the pointer, avoiding size_t overflow on 32-bit. Fixes: b691f64360ecec49 ("perf symbols: Implement poor man's ELF parser") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e525be3207edf8d450db03c75aca7259291f9ab6 Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 08:12:34 2026 -0300 perf symbols: Add bounds checks to elf_read_build_id() note iteration [ Upstream commit acc56d3941fc2997a5a21ea9233a8ac3d87c4f2f ] elf_read_build_id() iterates ELF notes using pointer arithmetic driven by n_namesz and n_descsz from the note headers. Neither the note header read nor the subsequent name/desc advances are checked against the section boundary. A malformed ELF file with oversized note sizes causes out-of-bounds reads past the section data buffer. Add two bounds checks: verify the note header fits within the remaining section data, and verify that namesz + descsz (after alignment) fits before advancing the pointer. Fixes: fd7a346ea292074e ("perf symbols: Filename__read_build_id should look at .notes section too") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 802257fbe4ea694968f1d8ea3f37852f12cc8b5c Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 08:12:04 2026 -0300 perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate insert [ Upstream commit a0e4362a3e7b592f1d58949ffe3d6decad39a17c ] When perf_env__insert_bpf_prog_info() returns false (duplicate program), the error path frees info_linear and info_node but not info_node->metadata. If bpf_metadata_create() had succeeded, the metadata allocation is permanently leaked. Fix by calling bpf_metadata_free() on info_node->metadata before freeing info_node. bpf_metadata_free() handles NULL, so this is safe even when bpf_metadata_create() returned NULL. Reported-by: sashiko-bot Fixes: fdc3441f2d317b40 ("perf record: collect BPF metadata from new programs") Cc: Blake Jones Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7e841b7b10147363a8cef9c59da8392f36a67f6f Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 08:11:28 2026 -0300 perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure [ Upstream commit aece2b8966fc8de5be46ee9287d0f60d6690c300 ] bpf_metadata_create() calls bpf_metadata_read_map_data() which allocates map.btf and map.rodata. If the subsequent bpf_metadata_alloc() fails, the code does 'continue' which skips bpf_metadata_free_map_data(), permanently leaking both allocations. Fix by calling bpf_metadata_free_map_data() before continue. Reported-by: sashiko-bot Fixes: ab38e84ba9a80581 ("perf record: collect BPF metadata from existing BPF programs") Cc: Blake Jones Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 77373bfa25646430816a1c5944053e58b8635492 Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 08:10:43 2026 -0300 perf bpf: Add NULL check for btf__type_by_id() in synthesize_bpf_prog_name() [ Upstream commit 903b0526dcf86d030c5970b4b0a67f9c227368e2 ] synthesize_bpf_prog_name() calls btf__type_by_id() and immediately dereferences the result via t->name_off without checking for NULL. btf__type_by_id() returns NULL when the type_id is invalid or out of range. When processing perf.data files, finfo->type_id comes from untrusted input, so an invalid ID causes a NULL pointer dereference. Fix by checking t for NULL before dereferencing. Reported-by: sashiko-bot Fixes: fc462ac75b36daaa ("perf bpf: Extract logic to create program names from perf_event__synthesize_one_bpf_prog()") Cc: Song Liu Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit df7d723d66bde3ddfd586b09d26751e72d255aba Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 08:10:18 2026 -0300 tools lib api: Fix mount_overload() snprintf truncation and toupper range [ Upstream commit fd1f70776add263f8ef38a87ae593c75303f1dcd ] mount_overload() builds an environment variable name like "PERF_SYSFS_ENVIRONMENT" from fs->name. Two bugs: 1) snprintf() uses name_len as the buffer size instead of sizeof(upper_name). For fs->name = "sysfs" (len=5), the output is truncated to "PERF" (4 chars + null), so getenv() never finds the intended variable. 2) mem_toupper() only uppercases name_len bytes, converting just the "PERF" prefix rather than the full string including the filesystem name portion. Fix by using sizeof(upper_name) for snprintf and strlen(upper_name) for mem_toupper, so the full "PERF_SYSFS_ENVIRONMENT" string is correctly formatted and uppercased. Reported-by: sashiko-bot Fixes: 73ca85ad364769ff ("tools lib api fs: Add FSTYPE__mount() method") Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 62adda4bb1b8e73b726bc431d684c5c3714c69a1 Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 07:05:19 2026 -0300 tools lib api: Fix filename__write_int() writing uninitialized stack data [ Upstream commit 438ece06185696e14c63c6113d5e2d34ec0a9680 ] filename__write_int() formats an integer into a 64-byte buffer with sprintf() then passes sizeof(buf) (64) as the write length. This writes all 64 bytes including uninitialized stack data past the formatted string. Most sysfs files reject the oversized write, making the function always return -1. Fix by capturing the sprintf() return value and using it as the write length. Reported-by: sashiko-bot Fixes: 3b00ea938653d136 ("tools lib api fs: Add sysfs__write_int function") Cc: Kan Liang Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 908bc5238979a65e7b39de07cbc86d710920728e Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 07:04:25 2026 -0300 perf tools: Use snprintf() in dso__read_running_kernel_build_id() [ Upstream commit 2ea64782a428bed74f595961e651ceb8c4c5bf22 ] dso__read_running_kernel_build_id() uses sprintf() to format a sysfs path from machine->root_dir into a PATH_MAX buffer. If root_dir is close to PATH_MAX in length, appending "/sys/kernel/notes" (18 bytes) overflows the stack buffer. Switch to snprintf() with sizeof(path) to prevent the overflow. Reported-by: sashiko-bot Fixes: cdd059d731eeb466 ("perf tools: Move dso_* related functions into dso object") Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1577822e1fa1985bf31838930f414688a6481df3 Author: Arnaldo Carvalho de Melo Date: Mon Jun 8 07:03:04 2026 -0300 perf hwmon: Guard label read against empty or failed reads [ Upstream commit 34d3d93fac6d92237cb9d730ca04c37ed361c7a6 ] hwmon_pmu__read_events() reads label files with read() into a stack buffer, strips trailing newlines, then checks buf[0] == '\0'. When read() returns 0 (empty file) or -1 (error), the buffer is never written, so buf[0] reads uninitialized stack memory. If the garbage byte is non-zero, the code falls through to strdup(buf) which copies arbitrary stack data as the label string. Fix by checking read_len <= 0 before accessing buf contents, closing the fd and skipping the entry. Reported-by: sashiko-bot Fixes: 53cc0b351ec99278 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2bfaa207732a17ea215adf86d14a9bb1d37ec2d0 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 22:43:09 2026 -0300 perf tools: Fix uninitialized pathname on uncompressed fallback in filename__decompress() [ Upstream commit 51cdb188edeaf389e4377859b9c483c19ce5a259 ] filename__decompress() has an early return path for files that are not actually compressed. This path returns the fd from open() directly but never writes to the pathname output parameter, leaving the caller with an uninitialized buffer despite a successful return. Callers like dso__decompress_kmodule_path() pass pathname to decompress_kmodule() which uses it to set the decompressed file path. If pathname is uninitialized, subsequent operations on the path produce undefined behavior. Fix by setting pathname to an empty string on the uncompressed path. Callers already check for an empty pathname to distinguish temporary decompressed files (which need unlink) from the original file. Reported-by: sashiko-bot Fixes: 7ac22b088afe26a4 ("perf tools: Add filename__decompress function") Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a11731df15af0a7bd62a5f5a06eec4b499615f90 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 22:40:20 2026 -0300 perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback [ Upstream commit 1b4e9fbdeabc549965e70ac0cd8095d57ff6df06 ] When sysfs__read_build_id() matches NT_GNU_BUILD_ID with the right namesz but the name content is not "GNU", it falls back to reading descsz bytes into the stack buffer bf[BUFSIZ]: } else if (read(fd, bf, descsz) != (ssize_t)descsz) Unlike the else branch which validates namesz + descsz against sizeof(bf), this path passes descsz directly to read() without any bounds check. A crafted sysfs file with a large n_descsz overflows the 8192-byte stack buffer. Add a descsz > sizeof(bf) check before the read, breaking out of the loop on oversized values. Fixes: e5a1845fc0aeca85 ("perf symbols: Split out util/symbol-elf.c") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 354a61c752ea4f649eec818c0b9a296dedc9373a Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 22:39:53 2026 -0300 perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow [ Upstream commit e1a2c9d70b312acc262f6be936dd5bbd9bbc6236 ] parse_hwmon_filename() strips the "_alarm" suffix from event names by copying into a 24-byte stack buffer: strlcpy(fn_type, fn_item, fn_item_len - 5); The third argument is the source length minus the suffix, not the destination buffer capacity. A long event name ending in "_alarm" can have fn_item_len - 5 > sizeof(fn_type), causing strlcpy() to write past the 24-byte fn_type[] array. The assert() only validates that the longest *valid* hwmon item fits, but does not protect against crafted input. Clamp the strlcpy size to min(fn_item_len - 5, sizeof(fn_type)). Fixes: 4810b761f812da3c ("perf hwmon_pmu: Add hwmon filename parser") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f99e250f8085f5302b474c936a91049a91a35230 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 22:38:48 2026 -0300 perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event() [ Upstream commit ae75956c166fe169b8c137bf375305fc97820a62 ] hwmon_pmu__for_each_event() formats description strings via: len = snprintf(desc_buf, sizeof(desc_buf), "%s in unit %s named %s.", ...); len += hwmon_pmu__describe_items(hwm, desc_buf + len, sizeof(desc_buf) - len, ...); If value->label is long enough to cause snprintf() to truncate, it returns the would-have-been-written count, making len exceed sizeof(desc_buf). The subsequent sizeof(desc_buf) - len underflows to a huge size_t value, disabling bounds checking in hwmon_pmu__describe_items(). The alias_buf snprintf has the same issue. Switch both to scnprintf() which returns actual bytes written. Fixes: 53cc0b351ec99278 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4c7ed5f4ff3673087afaf9ef1b8ccc65d7f6044d Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 22:38:26 2026 -0300 perf hwmon: Fix off-by-one null termination on sysfs reads [ Upstream commit 1847c5fae344a0fb9cc0f95be40b378359c6fc3b ] Three functions read sysfs files into fixed-size stack buffers using the full buffer size, then null-terminate at buf[read_len]. If the read fills the buffer exactly, read_len equals sizeof(buf) and the null byte writes one past the array, corrupting an adjacent stack variable. Fix all three by reading sizeof(buf) - 1 bytes, reserving space for the null terminator: - hwmon_pmu__read_events(): buf[128] - hwmon_pmu__describe_items(): buf[64] - evsel__hwmon_pmu_read(): buf[32] Fixes: 53cc0b351ec99278 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6290c0c0fb2b642d6a09bd113ece03618de2818d Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 22:37:55 2026 -0300 perf tools: Fix thread__set_comm_from_proc() on empty comm file [ Upstream commit 31d596054550f793508abe7dd593853ece47d428 ] thread__set_comm_from_proc() calls procfs__read_str() then strips the trailing newline via comm[sz - 1] = '\0'. procfs__read_str() allocates the buffer before reading, so on an empty /proc/pid/comm (reachable during late exit teardown) it returns success with sz = 0 and an unterminated heap buffer. The sz - 1 underflow was the original sashiko finding: it writes a null byte before the allocation. But even with a sz > 0 guard on the newline strip, the unterminated buffer would still be passed to thread__set_comm() which calls strlen() — an unbounded heap read. Fix by treating sz == 0 as failure: free the buffer and return -1. This is consistent with pmu.c's perf_pmu__parse_scale/unit which already treat len == 0 from filename__read_str as an error. Fixes: 2f3027ac28bf6bc3 ("perf thread: Introduce method to set comm from /proc/pid/self") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8532c1725abbb994c75c25f3168dfdac8bf34ac8 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:06:54 2026 -0300 perf intel-pt: Fix snprintf size tracking bug in insn decoder [ Upstream commit b6bb3b005dcdd960b8e0b7f9d6869132b3de08d5 ] dump_insn() tracks remaining buffer space with a 'left' variable, but the loop subtracts the cumulative offset 'n' each iteration instead of just the per-iteration delta: n += snprintf(x->out + n, left, "%02x ", inbuf[i]); left -= n; /* BUG: n is cumulative, not the delta */ After two iterations left goes massively negative, wrapping to a huge value when passed as size_t to snprintf(), disabling all bounds checking for the rest of the loop. Switch to scnprintf() accumulation using sizeof(x->out) - n as the remaining space, which is always correct and eliminates the separate 'left' variable entirely. Fixes: 48d02a1d5c137d36 ("perf script: Add 'brstackinsn' for branch stacks") Reported-by: sashiko-bot Cc: Adrian Hunter Cc: Andi Kleen Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5e5b4cfffb4af863021cd6a378f4b213e64df04e Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:06:12 2026 -0300 perf tools: Use mkostemp() for O_CLOEXEC on temporary files [ Upstream commit b8acc68f1382a3f380a0e7320a95d328ac5e9027 ] mkstemp() creates file descriptors without the close-on-exec flag. These fds leak to child processes spawned during symbol resolution (addr2line, objdump), wasting descriptors and potentially exposing temporary file contents. Replace mkstemp() with mkostemp(tmpbuf, O_CLOEXEC) at all three call sites: - filename__decompress() in dso.c - read_gnu_debugdata() in symbol-elf.c - kcore__init() in symbol-elf.c Fixes: 42b3fa670825983f ("perf tools: Introduce dso__decompress_kmodule_{fd,path}") Fixes: b10f74308e130527 ("perf symbol: Support .gnu_debugdata for symbols") Fixes: afba19d9dc8eba66 ("perf symbols: Workaround objdump difficulties with kcore") Reported-by: sashiko-bot Cc: Adrian Hunter Cc: Namhyung Kim Cc: Stephen Brennan Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 51d3124590bcfe028ea7bb4700f8529f21d068c6 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:05:15 2026 -0300 perf symbols: Bounds-check .gnu_debuglink section data [ Upstream commit 9c74f0aab398cb32ab250401f323c0fdc9a3a496 ] filename__read_debuglink() copies .gnu_debuglink section data into a caller-provided buffer via: strncpy(debuglink, data->d_buf, size); where size is PATH_MAX. If the ELF section is smaller than size and lacks a null terminator, strncpy reads past data->d_buf into adjacent memory. A malformed ELF file can trigger this, potentially causing a segfault or leaking heap data. Additionally, strncpy does not guarantee null termination when the source fills the buffer. Replace with an explicit memcpy bounded by both the output buffer size and the actual section data size (data->d_size), followed by explicit null termination. Fixes: e5a1845fc0aeca85 ("perf symbols: Split out util/symbol-elf.c") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 519b4ad15b2c21425732bce152b6f7be342a0bf1 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:04:50 2026 -0300 perf symbols: Fix signed overflow in sysfs__read_build_id() size check [ Upstream commit 6eaa8ee3e2abe5112e80e94c27196bb175689469 ] sysfs__read_build_id() reads ELF note headers from sysfs files. The note's namesz and descsz fields are used to compute the skip size: int n = namesz + descsz; if (n > (int)sizeof(bf)) Both namesz and descsz are size_t from NOTE_ALIGN() of 32-bit note header fields. Their sum can exceed INT_MAX, overflowing the signed int n to a negative value. The check n > sizeof(bf) then evaluates false (negative < positive in signed comparison), and read(fd, bf, n) reinterprets the negative n as a huge size_t count — the kernel writes up to MAX_RW_COUNT bytes into the 8192-byte stack buffer. In practice the overflow is bounded by the sysfs file's actual size, so a real sysfs notes file won't trigger it organically. But crafted input (e.g. via a mounted debugfs/sysfs image) could. Fix by validating namesz and descsz individually against the buffer size before summing, and change n to size_t to avoid the signed overflow entirely. Fixes: f1617b40596cb341 ("perf symbols: Record the build_ids of kernel modules too") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b4333af83c12cdf4efc882e991851beb17432324 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:03:55 2026 -0300 tools lib api: Fix missing null termination in filename__read_int/ull() [ Upstream commit 52b1f9678499b13b7aeb0186d9c6f486c043283f ] filename__read_int() passes a stack buffer to read() using the full sizeof(line) and then hands it to atoi() without null-terminating. If a sysfs file fills the 64-byte buffer exactly, atoi() reads past the array into uninitialized stack memory. filename__read_ull_base() has the same issue with strtoull(). Fix both by reading sizeof(line) - 1 bytes and explicitly null-terminating after a successful read. Fixes: 3a351127cbc682c3 ("tools lib fs: Adopt filename__read_int from tools/perf/") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a407a5177cd19a9b584e5d5ba8384cf3e46494c7 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:03:13 2026 -0300 perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs file [ Upstream commit 33035f7dd4e49f3f117e70c5e36c8c1ae88d37f2 ] perf_pmu__parse_scale() reads a PMU scale file then accesses scale[sret - 1] to strip a trailing newline. Only sret < 0 is guarded, so an empty file (sret == 0) causes scale[-1] — a stack buffer underflow that reads and potentially writes out of bounds. perf_pmu__parse_unit() has the same pattern: alias->unit[sret - 1] with sret == 0 accesses the byte before the struct member, which may corrupt the adjacent pmu_name pointer field. Change both guards from sret < 0 to sret <= 0 so that empty files are treated as read errors. Fixes: 410136f5dd96b601 ("tools/perf/stat: Add event unit and scale support") Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1202ebd3a9b49f24ee904c1386dd6bc8c1ce2c9e Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 21:01:43 2026 -0300 perf pmu: Fix pmu_id() heap underwrite on empty identifier file [ Upstream commit 836455e6dbd34eb3d12eeab5e2d2b9a7f1512459 ] pmu_id() calls filename__read_str() then strips the trailing newline via str[len - 1] = 0. If the PMU identifier file is empty, filename__read_str() succeeds with len = 0. len - 1 underflows size_t to SIZE_MAX, writing a null byte before the heap allocation. Add a len == 0 check before the newline stripping. Fixes: 51d548471510843e ("perf pmu: Add pmu_id()") Reported-by: sashiko-bot Cc: John Garry Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4d72f46d420fba747d3a11928297f9f6877d92da Author: James Clark Date: Tue Jun 9 15:40:06 2026 +0100 perf cs-etm: Queue context packets for frontend [ Upstream commit 68ca50bc0fa64841cd73b8a1538df1d7f7eb4108 ] PE_CONTEXT elements update the context ID and exception level, but the decoder may still have prior packets cached for frontend processing. Updating the context immediately in the decoder backend can make those cached packets get consumed with the wrong thread or EL state. Add a CS_ETM_CONTEXT packet carrying the TID and EL to the frontend, this keeps context changes ordered with the rest of the packet stream and avoids mismatches when synthesizing samples from cached packets. Separate the memory access function into one for the frontend and one for decoding. The frontend also needs memory access to attach the instruction to samples. Because the frontend does memory access for both previous and current packets, change all the frontend memory access function signatures to take both a tidq and packet. But backend always uses the current backend EL and thread from the tidq. Treat context packets as a boundary for branch sample generation and remove tidq->prev_packet_thread because it's not possible to branch to a different thread, so only tracking the current thread is required for sample generation. Fixes: e573e978fb12e160 ("perf cs-etm: Inject capabilitity for CoreSight traces") Reported-by: Amir Ayupov Closes: https://lore.kernel.org/linux-perf-users/20260515021135.1729028-1-aaupov@meta.com/ Co-authored-by: James Clark Signed-off-by: Leo Yan Cc: Ian Rogers Cc: Jiri Olsa Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: Mike Leach Cc: Namhyung Kim Cc: Paschalis Mpeis Cc: Robert Walker Cc: Shuah Khan Cc: Suzuki Poulouse Signed-off-by: James Clark Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit c091fe7073b0bb86f838459db9099f3223e99126 Author: Tanushree Shah Date: Sat Jun 6 17:45:29 2026 +0530 perf data convert json: Fix addr_location leak on time-filtered samples [ Upstream commit 2857a5dca750ea989c6fb70b4c14e801e4b7b4ad ] When samples are skipped due to time filtering in process_sample_event(), the early return path bypasses addr_location__exit(), causing memory leaks of thread, map, and maps references acquired by machine__resolve(). These references must be released through addr_location__exit() before returning. Fixes: 8e746e95c3e4eb56 ("perf data: Allow filtering conversion by time range") Reviewed-by: Ian Rogers Signed-off-by: Tanushree Shah Cc: Adrian Hunter Cc: Athira Rajeev Cc: Derek Foreman Cc: Hari Bathini Cc: Jiri Olsa Cc: Madhavan Srinivasan Cc: Michael Petlan Cc: Namhyung Kim Cc: Shivani.Nittor@ibm.com Cc: Tanushree.Shah@ibm.com Cc: Tejas.Manhas1@ibm.com Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d625d9b320c20681df6917225a0e2f42389bc687 Author: Jens Remus Date: Wed Jun 10 13:24:51 2026 +0200 perf s390: Fix TEXTREL in Python extension by compiling as PIC [ Upstream commit 49f5f6ae67dec54014584bb3126a5a94f14e2a5c ] On s390 the Python extension build fails as follows when using a linker that is configured to treat text relocations (TEXTREL) in shared libraries as error by default: GEN python/perf.cpython-314-s390x-linux-gnu.so /usr/bin/ld.bfd: error: read-only segment has dynamic relocations This occurrs because util/llvm-c-helpers.o is erroneously built from util/llvm-c-helpers.cpp without compiler option -fPIC but linked into the shared library (via libperf-util.a(perf-util-in.o)). On s390, object files must be compiled as position-indepedent code (PIC) in order to be linked into shared libraries. Commit a9a3f1d18a6c ("perf s390: Always build with -fPIC") added compiler option -fPIC to CFLAGS for s390, which is used in C compiles. Add -fPIC to CXXFLAGS for s390 as well, so that it is also used in C++ compiles. Fixes: a9a3f1d18a6c9ccf ("perf s390: Always build with -fPIC") Reported-by: Thomas Richter Reviewed-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Jens Remus Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Bill Wendling Cc: Heiko Carstens Cc: Hendrik Brueckner Cc: Ingo Molnar Cc: Jan Polensky Cc: Jiri Olsa Cc: Justin Stitt Cc: Mark Rutland Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 31298d37687b24e33e3d408aa38b3641cb095dc2 Author: Chuck Lever Date: Thu Jun 4 13:06:40 2026 -0400 xprtrdma: Return sendctx slot after Send preparation failure [ Upstream commit 60e7870052f417d83965db144f70ae21fcfcf37f ] rpcrdma_prepare_send_sges() gets a sendctx before it maps the SGEs for the Send WR. If one of the mapping helpers fails, no Send WR is posted, so no Send completion is guaranteed to advance rb_sc_tail. Current cleanup clears sc_req so a later completion can sweep over that slot, but a consecutive run of preparation failures can still advance rb_sc_head until the ring appears full. At that point rpcrdma_sendctx_get_locked() returns NULL and no Send can be posted to produce the completion needed to recover the ring. The trigger requires CONFIG_SUNRPC_XPRT_RDMA and an NFS/RDMA mount. Mount setup and reliable DMA-map fault injection require local admin authority. Unprivileged I/O on an existing mount can exercise the send path, but a remote peer alone cannot force this local DMA-map failure. Add rpcrdma_sendctx_unget_locked() for the single-consumer send path to rewind rb_sc_head when the just-acquired sendctx is canceled before ib_post_send(). Wake waiters after making the slot available again. After the rewind, every slot the completion sweep visits belongs to a posted Send, so rpcrdma_sendctx_put_locked() no longer needs to test sc_req before unmapping. Fixes: ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d7c531ab477ae94fd03771d707fd29c787408039 Author: Chuck Lever Date: Thu Jun 4 13:06:39 2026 -0400 xprtrdma: Repost Receive buffers for malformed replies [ Upstream commit abc011ddaf1617e3e82d8a1e87daa7ddbfb9bac5 ] rpcrdma_wc_receive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path. Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdma_post_recvs(). A remote peer can therefore drain the client's posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect. Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK terminates the connection. Refilling against rb_credits also restores the target that applied to malformed replies before commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one from connection establishment onward, so the repost path always keeps Receives posted. Fixes: 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 33db78b1b24fc6a464ae08aa4d2538c5f883eb5e Author: Chuck Lever Date: Thu Jun 4 13:06:38 2026 -0400 xprtrdma: Sanitize the reply credit grant after parsing [ Upstream commit c3a628aab2dc8f5fd7bff86ceaeae64de590e60a ] The out_norqst exit in rpcrdma_reply_handler() branches away before the credit clamp, so a reply that matches no pending request reaches out_post carrying the raw credit value parsed from the wire. rpcrdma_post_recvs() does not bound its @needed argument: the refill loop allocates and chains Receive WRs until the count is satisfied or allocation fails. A peer that sends a well-formed reply carrying an unknown XID and an inflated credit grant therefore drives rep allocation and Receive posting past re_max_requests on every such reply. Move the clamp to immediately after the credit field is parsed, ahead of the first branch that can reach out_post, so every later consumer sees a sanitized value. The cwnd update stays on the matched-request path. Fixes: 704f3f640f72 ("xprtrdma: Post receive buffers after RPC completion") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 118a16a18c59f7ad8084b2d13988839b669fca10 Author: Chris Mason Date: Thu Jun 4 13:06:37 2026 -0400 xprtrdma: Fix bcall rep leak and unbounded peek [ Upstream commit c7653d5cebc8492c77ec0415b5e9c0fb3e644bc6 ] rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()). Fixes: 41c8f70f5a3d ("xprtrdma: Harden backchannel call decoding") Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 69c956c1b67d58e9ffd120319c31664bdecc5609 Author: Chuck Lever Date: Thu Jun 4 13:06:36 2026 -0400 xprtrdma: Resize reply buffers before reposting receives [ Upstream commit 234c0ff695ef3ffb656931000e6b823d0c2f30fd ] Commit 0e13dd9ea8be ("xprtrdma: Remove temp allocation of rpcrdma_rep objects") made rpcrdma_rep objects survive disconnects. That is normally fine, but it also means their receive regbufs keep the size they had when they were first allocated. Each rep's receive buffer is sized to ep->re_inline_recv when the rep is created. rpcrdma_ep_create() resets that threshold to the rdma_max_inline_read ceiling for every new endpoint, and the connect handshake then shrinks it to the peer's advertised inline send size. A rep allocated under a smaller negotiated threshold keeps that size: on disconnect, rpcrdma_xprt_disconnect() drains and DMA-unmaps the surviving reps but does not free or resize them. The threshold can come back larger on the next connection. The first peer may supply no RPC-over-RDMA CM private data, defaulting its send size to 1024, while the reconnect target is an ordinary server offering 4096; or, with rdma_max_inline_read raised above its default, the reconnect target may advertise a larger svcrdma_max_req_size than the first. rpcrdma_post_recvs() then reposts a surviving rep whose SGE length is still the old, smaller value, and a larger inline Reply hits a receive length error and forces another disconnect. The undersized rep returns to the free list when its failed Receive flushes, so the following reconnect reposts the same rep and fails the same way. The transport flaps without making forward progress for as long as the peer keeps advertising the larger inline size. This is local/admin-triggerable rather than remote-triggerable: a local administrator must create and maintain the NFS/RDMA mount, while the server or reconnect target has to advertise a larger inline send size and return a reply that uses it. Fix this by checking each rep before it is reposted. If the receive regbuf is smaller than the current endpoint's inline receive size, reallocate it on the current RDMA device's NUMA node and reinitialize the rep's xdr_buf before DMA-mapping and posting the Receive WR. Fixes: 0e13dd9ea8be ("xprtrdma: Remove temp allocation of rpcrdma_rep objects") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 96da53e7d6f9da54dba0c1f13c85e018ba3d5eba Author: Chuck Lever Date: Tue May 26 10:14:05 2026 -0400 xprtrdma: Document and assert reply-handler invariants [ Upstream commit 797943e8bd1ffcc63bfe79d24faad9a77054ec40 ] The xprtrdma reply path has been the subject of recurring LLM-driven review claims that 'an RPC can complete while receive buffers are still DMA-mapped' or that 'the req can be freed while the HCA still owns the send buffer.' No runtime reproducer has surfaced, but the absence of a written-down invariant set lets each pass of automated review reach the same hypothetical conclusion. Subsequent fixes against ce2f9a4d9ccc ('xprtrdma: Decouple req recycling from RPC completion') closed the underlying races but did not document the closure where future readers will look for it. State the invariants explicitly in a comment above rpcrdma_reply_handler() and back four of them with WARN_ON_ONCE() probes positioned where each invariant is locally checkable on the previous patch's cleaned-up ownership state: - I1 (Receive WR ownership): WARN at rpcrdma_post_recvs() that a rep pulled from rb_free_reps carries rr_rqst == NULL. - I2 (rep attachment): WARN at rpcrdma_reply_put() that req->rl_reply was NULLed before the matching rep_put. - I3 (Registered-MR fence): WARN at rpcrdma_complete_rqst() that req->rl_registered is empty. Strong send-queue ordering of the LocalInv WR chain makes the last completion observe the ib_dma_unmap_sg() of every earlier MR, so 'list empty' implies 'all MRs unmapped'. - I4 (Send-buffer release): WARN at rpcrdma_req_release() that req->rl_sendctx is NULL. Reaching the kref release callback requires both the RPC-layer and Send-side references to have dropped; the Send-side drop runs in rpcrdma_sendctx_unmap(), which clears rl_sendctx (previous patch). A non-NULL rl_sendctx here would mean the Send-side owner had not run -- a contradiction. The XXX comment in xprt_rdma_free() about signal-driven release racing the Send completion described the pre-decouple state. Replace it with a one-line note pointing at the invariant set, since the kref scheme now holds the req across the in-flight Send regardless of which path released the rpc_task. I5 (req lifecycle) is stated in the comment but not probed: making it locally assertible would require moving kref_init out of rpcrdma_req_release(), which in turn requires adding kref_init to the bc_pa_list and backlog-wake reuse paths. That restructuring is deferred -- the invariant is unchanged either way. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Stable-dep-of: 234c0ff695ef ("xprtrdma: Resize reply buffers before reposting receives") Signed-off-by: Sasha Levin commit ef3b79edf14b6bfb0d21a26ccb0463f9cf82c6a9 Author: Chuck Lever Date: Thu Jun 4 13:06:35 2026 -0400 xprtrdma: Check frwr_wp_create() during connect [ Upstream commit 0f13fc7c7d2e0427517e63c739277a4cd338b0c5 ] frwr_wp_create() creates the singleton Memory Region used to encode padding for Write chunks whose payload length is not XDR-aligned. Its failure paths return a negative errno and leave ep->re_write_pad_mr set to NULL. rpcrdma_xprt_connect() currently ignores that return value. If frwr_wp_create() fails after the rest of the connection setup succeeds, xprt_rdma_connect_worker() treats the connection attempt as successful and sets XPRT_CONNECTED. A later NFS/RDMA read with a non-4-byte-aligned receive page length reaches rpcrdma_encode_write_list(), passes the NULL write-pad MR to encode_rdma_segment(), and dereferences it. This is locally triggerable on an NFS/RDMA client after a connect or reconnect hits a local MR allocation, DMA-map, MR-map, or post-send failure; a remote peer alone cannot force the local MR setup failure. Check the return value and fail the connect as -ENOTCONN, matching the adjacent setup failures. This keeps XPRT_CONNECTED clear and lets the normal reconnect path retry. Fixes: 21037b8c2258 ("xprtrdma: Provide a buffer to pad Write chunks of unaligned length") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 264ccd7871915749bee55fe0c39467a7f08d5479 Author: Chris Mason Date: Thu Jun 4 13:06:34 2026 -0400 xprtrdma: Initialize re_id before removal registration [ Upstream commit bb7caa63e1db22fd03e8dc591b12169e99169dff ] rpcrdma_create_id() registers ep->re_rn with the rpcrdma ib_client before returning the new rdma_cm_id to rpcrdma_ep_create(). However rpcrdma_ep_create() currently stores that pointer in ep->re_id only after rpcrdma_create_id() returns. A local administrator can race an NFS/RDMA mount against RDMA device removal. If rpcrdma_remove_one() observes the just-registered notification before rpcrdma_ep_create() assigns ep->re_id, rpcrdma_ep_removal_done() calls trace_xprtrdma_device_removal(NULL). The tracepoint dereferences id->device->name and copies id->route.addr.dst_addr, so the callback can crash the kernel with a NULL pointer dereference. Store the rdma_cm_id in ep->re_id immediately before publishing ep->re_rn. The existing error path still destroys the id directly if registration fails; ep is then freed by the caller without using ep->re_id. Remove the later duplicate assignment in rpcrdma_ep_create(). Fixes: 3f4eb9ff9234 ("xprtrdma: Handle device removal outside of the CM event handler") Assisted-by: kres:openai-gpt-5 Signed-off-by: Chris Mason Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit ffc07790539736a5d029f6a3c966b46c529f93a8 Author: Chris Mason Date: Thu Jun 4 13:06:33 2026 -0400 xprtrdma: Fix ep kref imbalance on ADDR_CHANGE [ Upstream commit af9b65b29af341932625c4283dc7a23cdb62688a ] rpcrdma_cm_event_handler() falls through to the disconnected: label on RDMA_CM_EVENT_ADDR_CHANGE and calls rpcrdma_ep_put() with no matching get when the event arrives before RDMA_CM_EVENT_ESTABLISHED. The kref then underflows during connect teardown and rpcrdma_xprt_disconnect() operates on a freed ep. Reference counts across a normal connection lifecycle: rpcrdma_ep_create() kref_init ->1 rpcrdma_xprt_connect() ep_get ->2 (before post_recvs) RDMA_CM_EVENT_ESTABLISHED ep_get ->3 RDMA_CM_EVENT_DISCONNECTED ep_put ->2 rpcrdma_xprt_drain() ep_put ->1 rpcrdma_xprt_disconnect() tail ep_put ->0 (ep_destroy) The connect-time get in rpcrdma_xprt_connect(), taken just before rpcrdma_post_recvs() "while there are outstanding Receives," is balanced by rpcrdma_xprt_drain. ADDR_CHANGE before ESTABLISHED has no get to consume, so its put drops the count to 1 and the drain put then frees the ep while rpcrdma_xprt_disconnect() still holds a pointer to it. Fix by dispatching on the prior re_connect_status via xchg(): for prev == 0 (pre-ESTABLISHED) wake the connect waiter and return with no put; for prev == 1 call rpcrdma_force_disconnect() and return. The case-1 arm relies on the subsequent RDMA_CM_EVENT_DISCONNECTED event -- reliably delivered when rdma_disconnect() is called on a still-connected cm_id -- to balance the ESTABLISHED get; rpcrdma_xprt_drain() continues to balance only that connect-time get. Any other prior value means teardown is already in flight. Fixes: 2acc5cae2923 ("xprtrdma: Prevent dereferencing r_xprt->rx_ep after it is freed") Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit f025990647c8bc3ea880df9eeeb5317d009558d3 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 14:36:57 2026 -0300 perf tools: Use scnprintf() in build_id__snprintf() and hwmon read_events() [ Upstream commit e33711d5e757011bb6d3506af4d6c97dad412b8f ] build_id__snprintf() and hwmon_pmu__read_events() accumulate formatted output via snprintf(), which returns the would-have-been-written count on truncation. In build_id__snprintf(), this inflates the return value beyond the buffer size. In hwmon_pmu__read_events(), len overshoots out_buf_len and the next 'out_buf_len - len' underflows. Switch both to scnprintf() which returns actual bytes written. In build_id__snprintf(), also tighten the loop guard from 'offs < bf_size' to 'offs + 1 < bf_size': since scnprintf() returns at most size-1, offs never reaches bf_size, and the original condition would spin doing zero-byte writes once the buffer fills. Fixes: fccaaf6fbbc59910 ("perf build-id: Change sprintf functions to snprintf") Fixes: 53cc0b351ec99278 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a6d9b818465688afce14444e8abb27c22b657947 Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 14:35:28 2026 -0300 perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path [ Upstream commit 227a8748742f0263f1fe3131449b44563b77a209 ] hists__scnprintf_title() accumulates formatted output into a buffer using scnprintf() for all filter clauses except the UID filter, which uses snprintf(). If the buffer fills up and snprintf() returns more than the remaining space, printed exceeds size and the next 'size - printed' underflows, causing later scnprintf() calls to write past the buffer. Switch the UID filter clause to scnprintf() to match the rest of the function. Fixes: 25c312dbf88ca402 ("perf hists: Move hists__scnprintf_title() away from the TUI code") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Arnaldo Carvalho de Melo Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5f3b8ff3f6320e8066131e896a961f9c1371c35e Author: Arnaldo Carvalho de Melo Date: Sun Jun 7 14:23:15 2026 -0300 perf bpf: Use scnprintf() in snprintf_hex() and synthesize_bpf_prog_name() [ Upstream commit cab3a9331ed0b3f884dd61c8a25b3cf123705982 ] Both functions accumulate formatted output via ret += snprintf(buf + ret, size - ret, ...). If the buffer is too small and snprintf() returns more than the remaining space, ret exceeds size and the next 'size - ret' underflows, causing snprintf() to write past the buffer end. Switch to scnprintf() which returns the actual number of bytes written, making the accumulation safe. Fixes: 7b612e291a5affb1 ("perf tools: Synthesize PERF_RECORD_* for loaded BPF programs") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Song Liu Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 01d67b6f44ed0e94a531442a0e77d6e8eccebb18 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 21:51:42 2026 -0300 perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code [ Upstream commit b145137fec13dc8fc7fcb14193ce395a1164e3a1 ] open() calls in dso.c and symbol-elf.c omit O_CLOEXEC, which leaks file descriptors to child processes spawned during symbol resolution (e.g., addr2line, objdump). This can exhaust the fd limit during long profiling sessions or when processing many DSOs. Add O_CLOEXEC to all open() calls in both files (12 call sites). Fixes: cdd059d731eeb466 ("perf tools: Move dso_* related functions into dso object") Fixes: e5a1845fc0aeca85 ("perf symbols: Split out util/symbol-elf.c") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a757d523741d0e050740d3ca0694948dcba96ca2 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 21:49:16 2026 -0300 perf sched: Fix idle-hist callchain display using wrong rb_first variant [ Upstream commit d9b99dc8148e0c1f5da3942131b47e0d21187a32 ] timehist_print_idlehist_callchain() calls rb_first_cached() on sorted_root, but the sort function (callchain_param.sort) populates it via rb_insert_color() on the plain rb_root member — not the cached variant. This means rb_leftmost is never set, so rb_first_cached() always returns NULL and the entire callchain summary is silently dropped from --idle-hist output. The original code in ba957ebb54893aca ("perf sched timehist: Show callchains for idle stat") was correct — it used struct rb_root and rb_first(). The bug was introduced when sorted_root was converted to rb_root_cached without converting the sort insertion path to use rb_insert_color_cached(). Use rb_first(&root->rb_root) to match how the tree was populated. Fixes: cb4c13a5137766c3 ("perf sched: Use cached rbtrees") Reported-by: sashiko-bot Cc: Davidlohr Bueso Cc: Namhyung Kim Acked-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 23af74f538b74090cb4aabf516d75b70c6d1adf8 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 21:48:13 2026 -0300 perf sched: Bounds-check prio before test_bit() in timehist [ Upstream commit 4477dc01fcfc7f404772a67e0c1e056541ceb61d ] timehist_skip_sample() reads prio from untrusted tracepoint data via perf_sample__intval(sample, "prev_prio") without bounds validation. A crafted perf.data with prev_prio >= MAX_PRIO (140) causes test_bit() to read past the end of the prio_bitmap, which is only MAX_PRIO bits. Add a prio >= 0 guard before the test_bit() call and skip out-of-range values (>= MAX_PRIO) that can never match the user's filter set. The original prio != -1 already let all negatives other than -1 through (after an undefined-behavior bitmap read); the new prio >= 0 guard preserves that pass-through behavior — negative means "no priority info", so the event is shown unfiltered — while fixing the OOB. Values >= MAX_PRIO are skipped because they cannot be represented in the filter bitmap. Fixes: 9b3a48bbe20d9692 ("perf sched timehist: Add --prio option") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Yang Jihong Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2c0461f5393b335cb18b178931b33482ed251bb4 Author: Lad Prabhakar Date: Thu May 21 10:12:56 2026 +0100 PCI: rcar-host: Remove unused LIST_HEAD(res) [ Upstream commit 6ba90ce2069ae923b0ec787aebdf2d786e5d2a58 ] Remove the unused LIST_HEAD(res) declaration from rcar_pcie_hw_enable(). The macro instantiation defines an unused 'struct list_head res' variable, which conflicts with a valid resource loop-local 'struct resource *res' declaration further down in the function, triggering a compiler variable shadowing warning: drivers/pci/controller/pcie-rcar-host.c:357:34: warning: declaration of 'res' shadows a previous local [-Wshadow] 357 | struct resource *res = win->res; Fixes: ce351636c67f75a9 ("PCI: rcar: Add suspend/resume") Signed-off-by: Lad Prabhakar Signed-off-by: Manivannan Sadhasivam Reviewed-by: Geert Uytterhoeven Reviewed-by: Marek Vasut Link: https://patch.msgid.link/20260521091256.15737-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Sasha Levin commit 027c177da2b559bc8e724732a8df6c9acc1a4444 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 21:31:51 2026 -0300 perf tools: NULL bitmap pointers after bitmap_free() [ Upstream commit a9e900bc5c5914aca750afafa459363e575d3046 ] Two call sites free bitmaps without NULLing the pointer, risking double-free if the structure is reused or cleanup is called twice: - mmap__munmap(): map->affinity_mask.bits - record__mmap_cpu_mask_free(): mask->bits Set each pointer to NULL after bitmap_free(). Fixes: 8384a2600c7ddfc8 ("perf record: Adapt affinity to machines with #CPUs > 1K") Fixes: f466e5ed6c356d1d ("perf record: Extend --threads command line option") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Alexey Budankov Cc: Alexey Bayduraev Cc: Arnaldo Carvalho de Melo Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit eb266a14c16a93eb4db7b56a452d6be93f8bdcd4 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 20:57:49 2026 -0300 perf tools: Use perf_env__get_cpu_topology() in machine__resolve() [ Upstream commit 5484b43a0ec8231c36fba6ead654cb72dbba8b8f ] machine__resolve() accesses env->cpu[al->cpu].socket_id after checking al->cpu >= 0 and env->cpu != NULL, but without validating al->cpu against env->nr_cpus_avail. Since al->cpu comes from the untrusted perf.data sample, a crafted file with a large CPU index causes an out-of-bounds heap read. Use perf_env__get_cpu_topology() which validates both NULL and bounds. Also bounds-check al->cpu before the cast to struct perf_cpu (int16_t): without this, values like 65536 silently truncate to 0, bypassing the accessor's internal check and returning CPU 0's topology. Fixes: 0c4c4debb0adda4c ("perf tools: Add processor socket info to hist_entry and addr_location") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Kan Liang Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 36d2c15a33ece8507678129f3c8e1d339ee52280 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 20:43:52 2026 -0300 perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow [ Upstream commit 7953a3a9b8e02e98c6e6958f291d0ae22393e46a ] cpu_map__snprint() accumulates snprintf() return values in ret. snprintf() returns the number of characters that *would have been written* on truncation, not the actual count. When a fragmented CPU list exceeds the buffer, ret grows past size, causing `size - ret` to underflow (both are size_t), and subsequent snprintf() calls write past the end of the caller's stack buffer. Switch to scnprintf() which returns the actual number of characters written, making ret accumulation safe by construction. Fixes: a24020e6b7cf6eb8 ("perf tools: Change cpu_map__fprintf output") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 678bb88bb97744fd14cf4b194153fcf035560b98 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 20:37:52 2026 -0300 perf tools: Fix get_max_num() size_t underflow on empty sysfs file [ Upstream commit 0a012113bb3a44482c163f16f4db03ccaa37a339 ] get_max_num() reads a sysfs file (cpu/possible, cpu/present, or node/possible) and scans backward from the end to find the last number. If the file is empty, filename__read_str() returns num == 0. The loop `while (--num)` decrements the size_t from 0 to SIZE_MAX, reading backward across the heap until a comma or hyphen is found or unmapped memory is hit. Add an early return for empty files before the backward scan. Fixes: 7780c25bae59fd04 ("perf tools: Allow ability to map cpus to nodes easily") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Don Zickus Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 962c7a1f8f1e1bf8547bc5f4de77d0614cf69038 Author: David E. Box Date: Fri May 29 11:31:49 2026 -0700 platform/x86/intel/vsec: Restore BAR fallback for header walk [ Upstream commit 375bbbbd112af028ee0b45d833a6233c23d19bbf ] The base_addr refactor changed intel_vsec_walk_header() to pass info->base_addr as the discovery-table base address. For the PCI VSEC driver this info comes from driver_data, but exported callers may provide their own static headers and leave base_addr unset. For xe, this made the discovery-table base address zero instead of the BAR selected by header->tbir, preventing PMT endpoints from being created. Restore the previous behavior for the header-walk path by falling back to pci_resource_start(pdev, header->tbir) when base_addr is not specified. Keep explicit base_addr override behavior unchanged. This preserves the refactor structure while fixing the functional regression in manual-header users. Fixes: 904b333fc51c ("platform/x86/intel/vsec: Refactor base_addr handling") Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: David E. Box Reviewed-by: Michael J. Ruhl Link: https://patch.msgid.link/20260529183150.129744-1-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c99444f6dfca893f6d310aae4a53c620f98f7b4f Author: Jamie Nguyen Date: Thu Jun 4 21:19:30 2026 -0700 fs/ntfs3: resize log->one_page_buf when adopting on-disk page size [ Upstream commit 5a35454179fe1041d9cd286f5d320ce0d448c12a ] log_replay() allocates log->one_page_buf using the page size that was chosen from the host PAGE_SIZE: log->one_page_buf = kmalloc(log->page_size, GFP_NOFS); Later, when a restart area is found, the log page size recorded on disk is adopted: t32 = le32_to_cpu(log->rst_info.r_page->sys_page_size); if (log->page_size != t32) { log->l_size = log->orig_file_size; log->page_size = norm_file_page(t32, &log->l_size, t32 == DefaultLogPageSize); } If the on-disk page size is larger than the size used for the initial allocation, log->page_size grows but one_page_buf is left at its original, smaller size. A subsequent unaligned read_log_page() then reads log->page_size bytes into the undersized scratch buffer: page_buf = page_off ? log->one_page_buf : *buffer; err = ntfs_read_run_nb_ra(ni->mi.sbi, &ni->file.run, page_vbo, page_buf, log->page_size, NULL, &log->read_ahead); overflowing the allocation. This is reachable when mounting a dirty NTFS volume whose log was formatted with a page size larger than the buffer initially allocated on the mounting host (for example a 64K-log volume mounted on a host that allocated a 4K scratch buffer). Grow one_page_buf when the adopted on-disk page size exceeds the size used for the initial allocation. On krealloc() failure the original buffer is left intact and freed by the existing error path. Fixes: b46acd6a6a627 ("fs/ntfs3: Add NTFS journal") Reported-by: Carol L Soto Signed-off-by: Jamie Nguyen Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 7ae7e98b71438c494532492cbf58fc0d7f7988bb Author: Edward Adam Davis Date: Tue May 26 16:08:04 2026 +0800 fs/ntfs3: prevent potential lcn remains uninitialized [ Upstream commit 57ac2831c8e0f168090d38e3de758c6a59db44db ] The target VCN being sought was not found within runs[0], causing run_lookup() to return false. This causes run_lookup_entry() to return false, which in turn results in a len value of 0, and the new parameter passed to attr_data_get_block() is NULL. Collectively, these factors ultimately cause attr_data_get_block_locked() to exit prematurely without initializing lcn, thereby triggering [1]. To prevent [1], the clen check within ni_seek_data_or_hole() has been moved to occur before the lcn check. [1] BUG: KMSAN: uninit-value in ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ntfs_llseek+0x22a/0x4a0 fs/ntfs3/file.c:1530 vfs_llseek fs/read_write.c:391 [inline] Fixes: c61326967728 ("fs/ntfs3: implement llseek SEEK_DATA/SEEK_HOLE by scanning data runs") Reported-by: syzbot+c2cfe997245202e46f10@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c2cfe997245202e46f10 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit b052df3a595348e917564293f926c83b4d3f3224 Author: Christian Fontanez Date: Mon May 18 21:33:20 2026 -0400 virtio: add missing kernel-doc for map and vmap members [ Upstream commit ac2c52e9f869897b6f4c0a54cf07da380ef2b8d6 ] Commit bee8c7c24b73 ("virtio: introduce map ops in virtio core") and commit b16060c5c7d5 ("virtio: introduce virtio_map container union") added 'map' and 'vmap' members to struct virtio_device but did not update the kernel-doc comment block. This caused 'make htmldocs' to emit warnings: ./include/linux/virtio.h:188 struct member 'map' not described in 'virtio_device' ./include/linux/virtio.h:188 struct member 'vmap' not described in 'virtio_device' Add the missing entries in struct-declaration order to match the existing convention in the file. After this patch, 'make htmldocs' no longer emits these warnings. Fixes: bee8c7c24b73 ("virtio: introduce map ops in virtio core") Fixes: b16060c5c7d5 ("virtio: introduce virtio_map container union") Reported-by: Luis Felipe Hernandez Signed-off-by: Christian Fontanez Signed-off-by: Michael S. Tsirkin Message-ID: <20260519013321.32511-1-christfontanez@gmail.com> Signed-off-by: Sasha Levin commit a2cc03ee5d34f9273fd16b2a716abd4ea5e63626 Author: Chuck Lever Date: Tue May 12 14:13:37 2026 -0400 lockd: Correct kernel-doc status descriptions for NLMv4 GRANTED [ Upstream commit 5412049208e669925f7b08bbfabe3cd28a598c5b ] NLM_GRANTED is a server-to-client callback; the local node responds in the role of the client. The kernel-doc for nlm4svc_proc_granted attributes NLM4_DENIED and NLM4_DENIED_GRACE_PERIOD to "the server", but per the Open Group XNFS specification the responder for this procedure is the client host, and NLM4_DENIED_GRACE_PERIOD identifies the client's own grace period after a reboot, not the server's. Rewrite the descriptions to match the spec: NLM4_DENIED reflects the generic internal-resource-constraint failure, and NLM4_DENIED_GRACE_PERIOD attributes the grace period to the client host that received the callback. Fixes: 7a9f7c8f934e ("lockd: Use xdrgen XDR functions for the NLMv4 GRANTED procedure") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ec52cdcbf23f67fd2b98cac07da80ae8a70cad75 Author: Shuvam Pandey Date: Mon May 18 22:44:18 2026 +0545 PCI: meson: Add missing remove callback [ Upstream commit 4b0dc84b293984f75598881809fb2d3daf54a2a8 ] meson_pcie_probe() powers on the PHY and registers the DesignWare host bridge with dw_pcie_host_init(), but the driver has no remove callback. On driver unbind or module unload, the driver core therefore proceeds to devres cleanup without first unregistering the host bridge or powering off the PHY. Add a remove callback that deinitializes the DesignWare host bridge and powers off the PHY while device-managed resources are still valid. Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Shuvam Pandey Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1a0c86ab264cdc1c79c917e984b90991af51d827.1779123847.git.shuvampandey1@gmail.com Signed-off-by: Sasha Levin commit 221972a90c56b64e665181893d08ffbde20d0fad Author: Shuvam Pandey Date: Mon May 18 13:49:40 2026 +0545 PCI: meson: Propagate devm_add_action_or_reset() failure [ Upstream commit b12341b98d5ac52f48ca1390e1e371aed81346c8 ] meson_pcie_probe_clock() enables a clock and then registers a devres action to disable it during teardown. If devm_add_action_or_reset() fails, it runs the action immediately, disabling the clock. The return value is currently ignored, so on that failure path, meson_pcie_probe_clock() returns the disabled clock and probe continues. Return the error so the existing probe error path unwinds normally. Fixes: 9c0ef6d34fdbf ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Shuvam Pandey Signed-off-by: Manivannan Sadhasivam Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/177909148011.9588.6639767953842842291@gmail.com Signed-off-by: Sasha Levin commit f966db2568c4b075a34243768b0c3ede1ea89d5e Author: Biju Das Date: Thu Jun 4 10:56:34 2026 +0100 pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages [ Upstream commit 898ab0f30e008e411ce93ddf81c4099abd9d4e46 ] dev_err_probe() internally calls dev_err() which uses pr_fmt() and printk(). Kernel log messages should end with a newline character to ensure proper log formatting. Add missing '\n' at the end of the error strings in rzg2l_gpt_probe(). Signed-off-by: Biju Das Link: https://patch.msgid.link/20260604095647.108654-5-biju.das.jz@bp.renesas.com Fixes: 061f087f5d0b ("pwm: Add support for RZ/G2L GPT") Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit fa7ce7dfbd2d88e080f50adf3f2c5d647fe40c3c Author: Li RongQing Date: Thu May 14 20:55:52 2026 -0400 PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro [ Upstream commit 282305d7e9c0e27fd8b4df34b7cd5506a1eccdd6 ] The original PCIE_FTS_NUM_L0(x) macro was buggy due to improper operator precedence, where ((x) & 0xff << 8) was evaluated as ((x) & 0xff00). Instead of just fixing the parentheses, use the standard FIELD_PREP() macro. This makes the code more robust by automatically handling masks and shifts, while also adding compile-time type and range checking to ensure the value fits within PCIE_FTS_NUM_MASK. Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller support") Signed-off-by: Li RongQing [mani: added the bitfield header include spotted by Sashiko] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krzysztof Wilczyński Link: https://patch.msgid.link/20260515005552.2343-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit e68035178e65e2b3aa386ce61202ff33724ae418 Author: Yang Erkun Date: Thu Feb 26 09:22:03 2026 +0800 nfs: use nfsi->rwsem to protect traversal of the file lock list [ Upstream commit 4837fb36219e6c08b666bc31a86841bad8526358 ] Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), it has been resolved after commit 0460253913e5 ("NFSv4: nfs4_do_open() is incorrectly triggering state recovery") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set. Reported-by: Li Lingfeng Closes: https://lore.kernel.org/all/20250419085709.1452492-1-lilingfeng3@huawei.com/ Closes: https://lore.kernel.org/all/20250715030559.2906634-1-lilingfeng3@huawei.com/ Fixes: c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update") Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 51e5adebef61bb2f9df7f48af572089b1353be7a Author: Mike Snitzer Date: Thu Jun 4 16:24:03 2026 -0400 NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in pg_get_mirror_count_write [ Upstream commit 1d62e659c0bf11649cf48e002c2a55d148f2610a ] The FF_FLAGS_NO_IO_THRU_MDS flag lives on each lseg, so any fallback decision made when there is no current lseg (e.g. between LAYOUTRETURN and the next LAYOUTGET) cannot run the per-lseg check. Introduce a sticky hdr-level ditto for FF_FLAGS_NO_IO_THRU_MDS in struct nfs4_flexfile_layout::flags (NFS4_FF_HDR_NO_IO_THRU_MDS bit), set whenever ff_layout_alloc_lseg() parses an lseg with the flag. The bit is never cleared for the lifetime of the layout hdr; the server is assumed to be consistent in its no-fallback policy per file. kzalloc() in ff_layout_alloc_layout_hdr() zero-initializes the field. Use the new ff_layout_hdr_no_fallback_to_mds() helper to gate ff_layout_pg_get_mirror_count_write(): when pnfs_update_layout() returns NULL (e.g. NFS_LAYOUT_BULK_RECALL, pnfs_layout_io_test_failed, pnfs_layoutgets_blocked) the existing code unconditionally calls nfs_pageio_reset_write_mds(). This is a source of unwanted WRITE to MDS. Fix it by checking NFS4_FF_HDR_NO_IO_THRU_MDS bit, and if set surface -EAGAIN instead; the writepage-side caller (nfs_do_writepage() for buffered, nfs_direct_write_reschedule() for O_DIRECT) then redirties the request so writeback retries via pNFS. Fixes: 260074cd8413 ("pNFS/flexfiles: Add support for FF_FLAGS_NO_IO_THRU_MDS") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0fe1ac2bda64813ab5baa93310051a51fc3c95e1 Author: Mike Snitzer Date: Thu Jun 4 16:24:02 2026 -0400 NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect errors [ Upstream commit 7a375cafc14ed151508f908ea5681caf0a9cc1d6 ] Commit f06bedfa62d5 ("pNFS/flexfiles: don't attempt pnfs on fatal DS errors") teaches ff_layout_{read,write}_pagelist() to return PNFS_NOT_ATTEMPTED when nfs4_ff_layout_prepare_ds() fails with a nfs_error_is_fatal() errno (e.g. -ETIMEDOUT from a SOFTCONN connect deadline, -ENOMEM, -ERESTARTSYS), so that the client gives up instead of spinning. pnfs_do_{read,write}() then dispatches the I/O through pnfs_{read,write}_through_mds() → nfs_pageio_reset_{read,write}_mds(). That fallback is unconditional and silently violates FF_FLAGS_NO_IO_THRU_MDS: when the layout segment carries the flag (typically single-mirror appliance layouts where MDS I/O is explicitly forbidden), the out_failed: path's \`&& !ds_fatal_error\` clause overrides the flag's short-circuit through ff_layout_avoid_mds_available_ds() and routes the I/O to the MDS file handle anyway. This is reachable in practice during a data-server restart: SOFTCONN exhaustion produces -ETIMEDOUT, which is fatal per nfs_error_is_fatal(), which triggers PNFS_NOT_ATTEMPTED, which silently goes to MDS. Preserve the upstream "don't spin on fatal errors" intent for layouts that permit MDS fallback. For layouts with FF_FLAGS_NO_IO_THRU_MDS set, mark the layout for return and request PNFS_TRY_AGAIN instead; if the server cannot supply a usable layout the failure now surfaces cleanly via pnfs_update_layout(), rather than via silent MDS I/O that contradicts the flag. Fixes: f06bedfa62d5 ("pNFS/flexfiles: don't attempt pnfs on fatal DS errors") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 7471673936d1848f263c6a7f07bac50d474e3440 Author: Clark Wang Date: Tue Jun 2 19:04:38 2026 +0800 nfs: keep PG_UPTODATE clear after read errors in page groups [ Upstream commit 3ff72e1cdf5c337b6acfcf3fcef748c5b9a5316b ] When a read request is split into multiple subrequests, earlier completions may advance PG_UPTODATE state for the page group once their bytes fall within hdr->good_bytes. If a later subrequest in the same group then completes with NFS_IOHDR_ERROR, the read path needs to clear any accumulated PG_UPTODATE state and keep later completions from rebuilding it. Otherwise, a subsequent successful subrequest can re-enter nfs_page_group_set_uptodate(), restore the page-group sync state, and leave stale PG_UPTODATE behind for nfs_page_group_destroy() to trip over in nfs_free_request(). Add a sticky page-group read-failed flag. Once any subrequest in the group is known to be bad, mark the group failed, clear any accumulated PG_UPTODATE state, and refuse further PG_UPTODATE synchronization for the rest of the completion walk. Fixes: 67d0338edd71 ("nfs: page group syncing in read path") Signed-off-by: Clark Wang Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 72c578ca2f9e5dba948d9f8166a9abda38695728 Author: Dai Ngo Date: Tue May 26 16:29:53 2026 -0700 NFSv4/pnfs: defer return_range callbacks until after inode unlock [ Upstream commit 77b160b2d863d37f36b6c38e80a7d259ce939e69 ] Sometimes unmounting an NFS filesystem mounted with pNFS SCSI layouts triggers the following warning: BUG: scheduling while atomic: umount.nfs4/... __schedule_bug+0xbd/0x100 schedule_debug.constprop.0+0x19f/0x220 __schedule+0x10d/0x10a0 schedule+0x74/0x190 schedule_timeout+0xf5/0x220 io_schedule_timeout+0xd5/0x160 __wait_for_common+0x186/0x4b0 blk_execute_rq+0x2ef/0x3a0 scsi_execute_cmd+0x1ff/0x700 sd_pr_out_command.isra.0+0x242/0x380 [sd_mod] bl_unregister_scsi.constprop.0+0x109/0x3c0 [blocklayoutdriver] bl_unregister_dev+0x175/0x1c0 [blocklayoutdriver] bl_free_device+0x1f/0x1b0 [blocklayoutdriver] bl_free_deviceid_node+0x12/0x30 [blocklayoutdriver] nfs4_put_deviceid_node+0x171/0x360 [nfsv4] ext_tree_remove+0x11c/0x1d0 [blocklayoutdriver] _pnfs_return_layout+0x416/0x900 [nfsv4] nfs4_evict_inode+0x108/0x130 [nfsv4] evict+0x316/0x750 dispose_list+0xf1/0x1a0 evict_inodes+0x33f/0x440 generic_shutdown_super+0xc9/0x4e0 kill_anon_super+0x3a/0x90 nfs_kill_super+0x44/0x60 [nfs] deactivate_locked_super+0xb8/0x1b0 cleanup_mnt+0x25a/0x380 task_work_run+0x13e/0x210 exit_to_user_mode_loop+0x169/0x400 do_syscall_64+0x467/0x1550 entry_SYSCALL_64_after_hwframe+0x76/0x7e The warning occurs because the block layout driver unregisters the SCSI device while the inode lock is still held. Device unregistration issues a SCSI PR command, which may sleep, resulting in a "scheduling while atomic" warning. During layout return, ext_tree_remove() invokes the layout driver's return_range callback while holding the inode lock. For block layouts, this callback eventually calls bl_unregister_scsi(), which may block in scsi_execute_cmd() while issuing PR commands to the device. Fix this by deferring the return_range callbacks until after the inode lock has been released. The layout header reference count is incremented before invoking return_range(), ensuring that the layout header remains valid while the layout driver removes extents from the extent tree. Fixes: c88953d87f5c8 ("pnfs: add return_range method") Signed-off-by: Dai Ngo Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 8203f760a72bd39a3b66bc4eff0aa272a99fe22b Author: Chuck Lever Date: Tue May 26 10:14:02 2026 -0400 xprtrdma: Decouple req recycling from RPC completion [ Upstream commit e786233d2e0bbff9a82e43f02ae3a46ab4b08ec3 ] rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them. Fixes: 0ab115237025 ("xprtrdma: Wake RPCs directly in rpcrdma_wc_send path") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 7c42bc9cb7d3d9b573b0b3b4fb9017c374587780 Author: Chuck Lever Date: Tue May 26 10:14:01 2026 -0400 xprtrdma: Use sendctx DMA state for Send signaling [ Upstream commit 2797ae7c929610fb2d2303a996a08173fa096730 ] Send signaling matters only when the prepared Send has page mappings to unmap. Today that test is expressed indirectly with rl_kref, because the Send-side reference is taken only for Sends with mapped SGEs. Split the SGE DMA unmap loop into its own helper and use sc_unmap_count directly for the signaling decision. This keeps the current behavior but removes one dependency on the old rl_kref semantics before the request lifetime rules are changed. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Stable-dep-of: e786233d2e0b ("xprtrdma: Decouple req recycling from RPC completion") Signed-off-by: Sasha Levin commit fa977d37765bb2746d26ea5bc00d287c241de162 Author: Sagi Grimberg Date: Wed May 13 09:58:24 2026 +0300 pNFS/filelayout: fix cheking if a layout is striped [ Upstream commit 91668417d4e925c98cae4a55b1b9860380ddbf16 ] A layout can still be striped with num_fh = 1 as it is perfectly possible that both MDS and DSs can handle the same filehandle. Hence check according to stripe_count > 1, which is the correct check to begin with. We should not be called with flseg->dsaddr = NULL, but if for some reason we do, return our best guess with is flseg->num_fh > 1. Fixes: a6b9d2fa0024 ("pNFS/filelayout: Fix coalescing test for single DS") Signed-off-by: Sagi Grimberg Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit f0dfbca47b9e342a4649d0b7d33131d58aeaf2c0 Author: Hongling Zeng Date: Wed May 13 17:28:59 2026 +0800 sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store() [ Upstream commit 37957478be021b92981aa4c99b69f308d3b784d0 ] xprt_create_transport() never returns NULL, only valid pointers or error pointers. Using IS_ERR_OR_NULL() is incorrect, and PTR_ERR(NULL) would return 0, which indicates EOF in a sysfs store function. Fix this by using IS_ERR() instead of IS_ERR_OR_NULL(). Fixes: df210d9b0951 ("sunrpc: Add a sysfs file for adding a new xprt") Signed-off-by: Hongling Zeng Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit e2414f2a3f1282b726a90b494137afb57bb86208 Author: Phillip Varney Date: Fri Jun 5 00:55:45 2026 +0000 clk: qcom: a53: Corrected frequency multiplier for 1152MHz [ Upstream commit bb56147ea9fce98ebde1d367335ba006cba61fbd ] The 1152MHz frequency entry for the a53 currently selects a multiplier of 62, giving 1190MHz. This changes the mulitiplier to 60 giving the intended 1152MHz. Signed-off-by: Phillip Varney Reviewed-by: Konrad Dybcio Fixes: 0c6ab1b8f894 ("clk: qcom: Add A53 PLL support") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260605005502.313928-1-pbvarney@protonmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 65e82fa24965b2eb6ad9412f6c530ed9a50a625f Author: Nuno Sá Date: Fri Apr 24 18:40:17 2026 +0100 dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor [ Upstream commit 9e942c8579130e62734c14338e9f451780669164 ] For architectures like Microblaze or arm64 (where this IP is used), DMA_DIRECT_REMAP is set which means that dma_alloc_coherent() might remap (and hence vmalloc()) some memory. This became visible in a design where dma_direct_use_pool() is not possible. With the above, when calling dma_free_coherent(), vunmap() would be called from softirq context and thus leading to a BUG(). To fix it, use a dma pool that is allocated in .device_alloc_chan_resources() and allocate blocks from it. The key point is that now dma_pool_free() is used in axi_dmac_free_desc() to free the blocks and that just frees the blocks from the pool in the sense they can be used again. In other words, no actual call to dma_free_coherent() happens. That only happens when destroying the pool in axi_dmac_free_chan_resources() which does not happen in any interrupt context. Fixes: 3f8fd25936ee ("dmaengine: axi-dmac: Allocate hardware descriptors") Signed-off-by: Nuno Sá Reviewed-by: Frank Li Link: https://patch.msgid.link/20260424-dma-dmac-handle-vunmap-v4-4-90f43412fdc0@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f055829151eed5a9ec4af98a6c1ce75dbaf2e372 Author: Nuno Sá Date: Fri Apr 24 18:40:15 2026 +0100 dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc [ Upstream commit 4910ce1b3b35687bb2a5e742c4bfbea3c647c980 ] Use axi_dmac_free_desc() to free fully the descriptor at fail path when call axi_dmac_alloc_desc() in axi_dmac_prep_peripheral_dma_vec(). Fixes: 74609e568670 ("dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec") Signed-off-by: Nuno Sá Reviewed-by: Frank Li Link: https://patch.msgid.link/20260424-dma-dmac-handle-vunmap-v4-2-90f43412fdc0@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0bc191050c3253da8ef4bfaf157c44efed6e22cd Author: Nuno Sá Date: Fri Apr 24 18:40:14 2026 +0100 dmaengine: Fix possible use after free [ Upstream commit 92f853f0645aebf1d05d333e97ab7c342ace1892 ] In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check. Fixes: 0f571515c332 ("dmaengine: Add privatecnt to revert DMA_PRIVATE property") Signed-off-by: Nuno Sá Reviewed-by: Frank Li Link: https://patch.msgid.link/20260424-dma-dmac-handle-vunmap-v4-1-90f43412fdc0@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c1a2159c11004c338f2f3ae16857f478cd9809ed Author: Icenowy Zheng Date: Tue Jun 2 15:03:44 2026 +0800 dmaengine: qcom: gpi: set DMA_PRIVATE capability [ Upstream commit 4e351f408743354d54ee1af5193fc78234f2044e ] The GPI DMA controller is only responsible for QUP peripherals, and cannot work as a general-purpose DMA accelerator. Set DMA_PRIVATE capability for it. This fixes error messages about GPI being shown when an async-tx consumer is loaded. Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Signed-off-by: Icenowy Zheng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260602070344.3707256-1-zhengxingda@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fb372cbccab661a6beeb7d25ce9b91bbae8b1321 Author: Junrui Luo Date: Thu Apr 16 22:18:05 2026 +0800 mshv: add bounds check on vp_index in mshv_intercept_isr() [ Upstream commit a4ffc59238be84dd1c26bf1c001543e832674fc6 ] mshv_intercept_isr() extracts vp_index from the hypervisor message payload and uses it directly to index into pt_vp_array without validation. handle_bitset_message() and handle_pair_message() already validate vp_index against MSHV_MAX_VPS before array access. Add the same MSHV_MAX_VPS bounds check for consistency with the other message handlers. Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 89acfa8ad3af8c3e0152d427932daebd468ec466 Author: Pratyush Yadav (Google) Date: Fri Jun 5 18:06:44 2026 +0200 docs: memfd_preservation: fix rendering of ABI documentation [ Upstream commit 3a358c78093f98a70d84c934b7054f636bc846f2 ] The "memfd Live Update ABI" section in include/linux/kho/abi/memfd.h currently does not render in the exported documentation. This is because it should not include the "DOC:" in its reference. Drop it to ensure correct rendering. Tested by running make htmldocs. Fixes: 15fc11bb2cb6 ("docs: add documentation for memfd preservation via LUO") Signed-off-by: Pratyush Yadav (Google) Tested-by: Randy Dunlap Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260605160645.3650271-1-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 2ce2a2e19b62d962fd7df766784b59d70634066d Author: Jagadeesh Kona Date: Thu May 7 11:08:29 2026 +0530 clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks [ Upstream commit 1e6ae74ac6f28ace7a0eb84897c6e17bb044e5de ] Add support for camera QDSS debug clocks on X1E80100 platform which are required to be voted for camera icp and cpas usecases. This change aligns the camcc driver to the new ABI exposed from X1E80100 camcc bindings that supports these camcc QDSS debug clocks. Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Signed-off-by: Jagadeesh Kona Fixes: 76126a5129b5 ("clk: qcom: Add camcc clock driver for x1e80100") Link: https://lore.kernel.org/r/20260507-purwa-videocc-camcc-v5-4-fc3af4130282@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ca461a2a7390084360c865a1338c0e9b4f1a4de7 Author: Jagadeesh Kona Date: Thu May 7 11:08:27 2026 +0530 dt-bindings: clock: qcom: Add X1P42100 camera clock controller [ Upstream commit 97a5e120be5d3d7cf7d221b8703921046b73f0d2 ] Add X1P42100 camera clock controller support and clock bindings for camera QDSS debug clocks which are applicable for both X1E80100 and X1P42100 platforms. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20260507-purwa-videocc-camcc-v5-2-fc3af4130282@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 1e6ae74ac6f2 ("clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks") Signed-off-by: Sasha Levin commit a0c08cdaf63a09cf16ca0efd2a02c89f1fa1c1a8 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 11:33:41 2026 -0300 perf sched: Free callchain nodes in idle thread cleanup [ Upstream commit c3e51ed45ffa7547495a851e33ce332f81ef3665 ] free_idle_threads() relies on the thread priv destructor (free()) to clean up idle_thread_runtime structs. But free() doesn't walk the callchain_cursor linked list or the callchain_root tree allocated by callchain_cursor__copy() and callchain_append() during --idle-hist processing. Every idle thread with callchain data leaks these nodes. Introduce callchain_cursor_cleanup() to free the cursor's linked list of callchain_cursor_node entries, and call it together with free_callchain() in free_idle_threads() before thread__put(). Fixes: 225b24f569980ac9 ("perf sched timehist: Save callchain when entering idle") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5e7c076511bf4738c20ef35aa56e59d71f8ac9cf Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 11:25:40 2026 -0300 perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num() [ Upstream commit 33fa2bf5608fc36bc25231592145f4738f14f11b ] set_max_cpu_num() assigns the sysfs "possible" CPU count to max_cpu_num.cpu which is int16_t (struct perf_cpu). On systems with >32767 possible CPUs the value silently truncates, potentially wrapping negative. This causes cpunode_map to be underallocated and subsequent cpu__get_node() calls to read out of bounds. The matching check for max_present_cpu_num was added by commit c760174401f6 ("perf cpumap: Reduce cpu size from int to int16_t") but max_cpu_num was missed. Add the same INT16_MAX guard. Fixes: c760174401f605cf ("perf cpumap: Reduce cpu size from int to int16_t") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit cb47a3546f523bcbf5d77d23ed83aa53f7acb43a Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 11:21:32 2026 -0300 perf timechart: Fix cpu2y() OOB read on untrusted CPU index [ Upstream commit e2496db45bfd8dfb6154ec415798fee330f1cc0a ] cpu2y() indexes topology_map[cpu] without bounds checking. The array is allocated with nr_cpus entries (from env->nr_cpus_online), but callers pass sample CPU values from perf.data which can exceed that size with cross-machine recordings. Track the topology_map allocation size and bounds-check the CPU argument in cpu2y() before indexing. Out-of-bounds CPUs fall back to the identity mapping (cpu2slot(cpu)), which is the same behavior as when no topology is available. Fixes: c507999790438cde ("perf timechart: Add support for topology") Reported-by: sashiko-bot Cc: Stanislav Fomichev Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 231acb6d0e14609ea83bdf4bc3eca738085eefdd Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 11:19:10 2026 -0300 perf c2c: Fix use-after-free in he__get_c2c_hists() error path [ Upstream commit 5e5e6196d737c5be03d20647428316b36621608d ] he__get_c2c_hists() assigns c2c_he->hists before calling c2c_hists__init(). If init fails, the error path calls free(hists) but leaves c2c_he->hists pointing to freed memory. On teardown, c2c_he_free() finds the non-NULL pointer and calls hists__delete_entries() on it, causing a use-after-free. Set c2c_he->hists to NULL before freeing so teardown skips the already-freed allocation. Fixes: b2252ae67b687d2b ("perf c2c report: Decode c2c_stats for hist entries") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 423c520416d7ea069c2386a83503b60017158134 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 11:17:45 2026 -0300 perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu [ Upstream commit afa4363a91a19dff65dceb7fbce7bba689bbc854 ] process_cpu_topology() in header.c frees env->cpu on old-format perf.data files that predate topology information, but leaves nr_cpus_avail set. The six perf_env__get_*_aggr_by_cpu() functions in builtin-stat.c pass the bounds check but dereference a NULL env->cpu pointer, crashing on old recordings. Introduce perf_env__get_cpu_topology() as a safe accessor that validates env->cpu, cpu.cpu >= 0, and cpu.cpu < nr_cpus_avail in one place, returning a struct cpu_topology_map pointer or NULL. Convert all six topology aggregation callbacks to use it. Fixes: 88031a0de7d68d13 ("perf stat: Switch to cpu version of cpu_map__get()") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6cfa75ce9a8232ca350d774cdd63c6bcded6f3b2 Author: Arnaldo Carvalho de Melo Date: Sat Jun 6 11:03:29 2026 -0300 perf mmap: Fix NULL deref in aio cleanup on alloc failure [ Upstream commit 25627346b10e6a564610ea2c49dc6dd54812226d ] perf_mmap__aio_mmap() sets map->aio.nr_cblocks before allocating the data array. If calloc() for aiocb or cblocks fails before the data array is allocated, the return -1 path leads to perf_mmap__aio_munmap() which loops nr_cblocks times calling perf_mmap__aio_free(). Both versions of perf_mmap__aio_free() (NUMA and non-NUMA) dereference map->aio.data[idx] without checking if data is NULL, causing a NULL pointer dereference. Add NULL checks for map->aio.data at the top of both perf_mmap__aio_free() variants so the cleanup path is safe when allocation fails partway through perf_mmap__aio_mmap(). Fixes: d3d1af6f011a553a ("perf record: Enable asynchronous trace writing") Reported-by: sashiko-bot Cc: Alexey Budankov Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f09f7be6bba10138727b58b207ab0d7977ec1c82 Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 11:26:28 2026 -0300 perf sched: Replace BUG_ON and add NULL checks in replay event helpers [ Upstream commit 75eafe4a3a93a0143a20c0cc286bfb9008ac1478 ] get_new_event() has three issues: 1. The zalloc() result is dereferenced without a NULL check, crashing on allocation failure. 2. BUG_ON(!task->atoms) kills the process when realloc() fails. Since perf.data is untrusted input, this should be a graceful error. 3. The realloc pattern assigns directly to task->atoms, losing the old pointer on failure. task->nr_events is also incremented before the realloc, leaving corrupted state on failure. Fix get_new_event() to: - Check the zalloc() result before dereferencing - Use a temporary for realloc() to avoid losing the old pointer - Increment nr_events only after successful realloc - Return NULL instead of calling BUG_ON on failure Also fix add_sched_event_wakeup() where zalloc() for wait_sem is passed to sem_init() without a NULL check. Update all callers (add_sched_event_run, add_sched_event_wakeup, add_sched_event_sleep) to handle NULL returns by returning early. The replay may produce incomplete output on OOM but will not crash. Fixes: ec156764d424 ("perf sched: Import schedbench.c") Reported-by: sashiko-bot Cc: Ingo Molnar Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6380a4f550dc4f4e98f51d167cb4f28650561cc0 Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 11:17:03 2026 -0300 perf sched: Use thread__put() in free_idle_threads() [ Upstream commit a99d6394cd48fed75b1d24733d5afe6837a61a3f ] free_idle_threads() calls thread__delete() directly instead of thread__put(), bypassing the reference counting lifecycle. Under REFCNT_CHECKING builds, this leaks the pointer handle since thread__delete() frees the object without going through the refcount wrapper. The idle threads are created via thread__new() (refcount=1) in get_idle_thread(). Callers get additional references via thread__get() which they release with thread__put(). free_idle_threads() drops the base reference — thread__put() is the correct call, matching the thread__new() acquisition. Fixes: 49394a2a24c7 ("perf sched timehist: Introduce timehist command") Reported-by: sashiko-bot Cc: David Ahern Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1f0a529864d8097ede023ba2204455e2de5d72dd Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 11:15:58 2026 -0300 perf sched: Fix thread reference leak in idle hist processing [ Upstream commit 662d56d48e527ee21a0b03082ee318258a6f7919 ] timehist_sched_change_event() sets itr->last_thread to NULL at the end of idle hist processing without calling thread__put() first. The thread reference was acquired via thread__get() in timehist_get_thread() (line 2581), so every idle context switch leaks a thread reference when --idle-hist is active. Use thread__zput() to properly release the reference before clearing the pointer. Fixes: 5d8f17fb5822 ("perf sched timehist: Add -I/--idle-hist option") Reported-by: sashiko-bot Cc: David Ahern Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3ba9b69aef73cdecd016d6a2d0284c03248d8f3f Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 19:01:35 2026 -0300 perf sched: Use is_idle_sample() for idle thread runtime cast guard [ Upstream commit c9b3054c99cafd5f5f92158101760992a83e5a5e ] timehist_sched_change_event() uses thread__tid(thread) == 0 to decide whether to cast thread_runtime to idle_thread_runtime. However, a crafted perf.data can set common_pid=0 and common_tid=0 (the perf_sample fields) while prev_pid != 0 (the tracepoint field). is_idle_sample() returns false (it checks prev_pid for sched_switch), so timehist_get_thread() goes through machine__findnew_thread() and returns the machine's TID 0 thread — whose priv data is a regular thread_runtime, not the larger idle_thread_runtime allocated by init_idle_thread(). The subsequent cast to idle_thread_runtime reads past the thread_runtime allocation, accessing itr->last_thread, itr->cursor, and itr->callchain from adjacent heap memory. Writing to itr->last_thread corrupts the heap; calling thread__put() on the OOB value frees an arbitrary pointer. Replace the thread__tid() == 0 check with is_idle_sample(), which uses the tracepoint-specific prev_pid field and correctly identifies whether the sample originated from an idle thread with idle_thread_runtime priv. Fixes: 5d8f17fb5822 ("perf sched timehist: Add -I/--idle-hist option") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 340b08cfa751dfdb0020b51ab3f931d1a871d1b9 Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 11:12:08 2026 -0300 perf sched: Clean up idle_threads entry on init failure [ Upstream commit cda5a94ad9181cd60cbf04be11d524201bf489a2 ] get_idle_thread() allocates a thread via thread__new() and stores it in idle_threads[cpu], then calls init_idle_thread() to set up the private data. If init_idle_thread() fails (e.g. OOM for the idle_thread_runtime struct), the function returns NULL but leaves the partially initialized thread in idle_threads[cpu]. On subsequent calls for the same CPU, get_idle_thread() finds a non-NULL idle_threads[cpu], skips allocation, and returns thread__get() on a thread that has no priv data. Callers then get a thread whose thread__priv() returns NULL, leading to unexpected behavior. Release the thread and reset the slot to NULL on init failure so the entry doesn't persist in a corrupted state. Fixes: 49394a2a24c7 ("perf sched timehist: Introduce timehist command") Reported-by: sashiko-bot Cc: David Ahern Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4884cfb0d36d0fe92c2189aff5a9ca03073f6e21 Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 11:06:30 2026 -0300 perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop [ Upstream commit 5fb2e6ad8c5d6b3b380f94c7456595511f3731be ] setup_nodes() iterates CPU maps from the perf.data topology header and uses cpu.cpu directly as an array index into cpu2node[] (allocated with c2c.cpus_cnt = env->nr_cpus_avail entries) and __set_bit(cpu.cpu, set) (bitmap also sized to c2c.cpus_cnt). A crafted perf.data with topology CPU IDs exceeding nr_cpus_avail causes out-of-bounds heap writes into both the cpu2node array and the per-node bitmap. Add a bounds check to skip CPU IDs that fall outside the valid range. Fixes: 1e181b92a2da ("perf c2c report: Add 'node' sort key") Reported-by: sashiko-bot Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 937be22cf6d211dd87da2635b89a455aeecb6e50 Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 11:05:13 2026 -0300 perf c2c: Bounds-check CPU and node IDs before bitmap and array access [ Upstream commit 65117c3da50f749f4c22eb7a7effc53453dff57f ] c2c_he__set_cpu() passes sample->cpu directly to __set_bit(cpu, cpuset) after only checking for the (u32)-1 sentinel. The cpuset bitmap is allocated with c2c.cpus_cnt bits (from env->nr_cpus_avail), so a crafted perf.data with CPU IDs exceeding that count causes out-of-bounds heap writes. c2c_he__set_node() similarly passes the node ID from mem2node__node() to __set_bit(node, nodeset) after only checking for negative values. The nodeset bitmap is sized to c2c.nodes_cnt (from env->nr_numa_nodes), so a node ID exceeding that causes OOB writes. process_sample_event() indexes c2c.cpu2node[cpu] and c2c_he->node_stats[node] without bounds checking. Both arrays are sized to c2c.cpus_cnt and c2c.nodes_cnt respectively. Add bounds checks in all three paths: - c2c_he__set_cpu(): return if sample->cpu >= c2c.cpus_cnt - c2c_he__set_node(): return if node >= c2c.nodes_cnt - process_sample_event(): clamp cpu to 0 if >= cpus_cnt, guard node_stats access with bounds check Fixes: 1e181b92a2da ("perf c2c report: Add 'node' sort key") Reported-by: sashiko-bot Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9cbb9f3e532eb1bb79c6559fa551c9fe2579ff3d Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 10:59:11 2026 -0300 perf stat: Bounds-check CPU index in topology aggregation callbacks [ Upstream commit 52e69b1c5b606b513d403dd4addc784c27a0c8e2 ] Six perf_env__get_*_aggr_by_cpu() functions access env->cpu[cpu.cpu] after only checking cpu.cpu != -1. env->cpu[] is allocated with env->nr_cpus_avail entries, so a CPU index from an untrusted perf.data file that exceeds that count causes an out-of-bounds heap read. Replace the != -1 guard with >= 0 && < env->nr_cpus_avail in all six functions. The >= 0 check also catches -1 and any other negative values that could bypass the old check. Affected functions: - perf_env__get_socket_aggr_by_cpu() - perf_env__get_die_aggr_by_cpu() - perf_env__get_cache_aggr_by_cpu() - perf_env__get_cluster_aggr_by_cpu() - perf_env__get_core_aggr_by_cpu() - perf_env__get_cpu_aggr_by_cpu() Fixes: 68d702f7a120 ("perf stat report: Add support to initialize aggr_map from file") Reported-by: sashiko-bot Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5257dfb9619cc1a67aae5223a44d976e99701e1b Author: Arnaldo Carvalho de Melo Date: Fri Jun 5 10:56:33 2026 -0300 perf mmap: Guard cpu__get_node() return in aio_bind() [ Upstream commit f32dc302a090f48893477ef297a888db109ec0bd ] perf_mmap__aio_bind() passes the cpu__get_node() return value directly to an unsigned long variable (node_index). When cpu__get_node() returns -1 for an unknown CPU, the implicit int-to-unsigned-long conversion sign-extends it to ULONG_MAX. This causes bitmap_zalloc(ULONG_MAX + 1) which wraps to bitmap_zalloc(0), returning a zero-sized allocation. The subsequent __set_bit(ULONG_MAX, node_mask) then writes massively out of bounds. Check the return value in a signed temporary before assigning to node_index, and skip the NUMA binding when the node is unknown. Fixes: c44a8b44ca9f ("perf record: Bind the AIO user space buffers to nodes") Reported-by: sashiko-bot Cc: Alexey Budankov Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5ea1dcc9418c4e06ce29ed5170596f497ba86872 Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 18:25:57 2026 -0300 perf sched: Fix register_pid() overflow, strcpy, and BUG_ON [ Upstream commit 5949d339f5ec98752d56dcd4e36f619a59d513a5 ] register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result. Fixes: ec156764d424 ("perf sched: Import schedbench.c") Reported-by: sashiko-bot Cc: Ingo Molnar Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 68b6157d2c626aeed825be74f6db539504f033d2 Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 18:23:35 2026 -0300 perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing [ Upstream commit 06e7994427ab56e32699a5e45d048ff0826f3d53 ] perf_timehist__process_sample() updates sched->max_cpu from the sample CPU without bounds checking. Later code uses max_cpu + 1 as an iteration count over arrays allocated with MAX_CPUS entries (curr_thread, cpu_last_switched). A recording with CPU IDs >= MAX_CPUS causes out-of-bounds array accesses. Also cap the env->nr_cpus_online initialization of max_cpu in perf_sched__timehist(), which could exceed MAX_CPUS on very large systems. Add bounds checks before both max_cpu updates, matching the pattern already used in map_switch_event(). Fixes: 49394a2a24c7 ("perf sched timehist: Introduce timehist command") Reviewed-by: David Ahern Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 380ad7297fa0c24e0de0235075d986af21cec9bc Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 18:18:05 2026 -0300 perf sched: Fix thread reference leaks in timehist_get_thread() [ Upstream commit fa20c1f8f4e094abe0169d39fce8181bc26d6dab ] timehist_get_thread() acquires a thread reference via machine__findnew_thread() and an idle thread reference via get_idle_thread() (which calls thread__get()). Two error paths in the idle_hist block return NULL without releasing these references: - When get_idle_thread() fails, the thread reference leaks. - When thread__priv(idle) returns NULL, both idle and thread leak. Additionally, the idle thread reference acquired on the success path is never released, leaking a reference on every sample when --idle-hist is active. Add thread__put() calls on both error paths and release the idle reference after use on the success path. Fixes: 5d8f17fb5822 ("perf sched timehist: Add -I/--idle-hist option") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6587c61570f4c15eb4314355e88f67857be31221 Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 18:14:23 2026 -0300 perf tools: Add bounds check to cpu__get_node() [ Upstream commit 1e7921d7227de5da0dfc167943092c823ec7e49b ] cpu__get_node() accesses cpunode_map[cpu.cpu] without checking against max_cpu_num, the allocation size of cpunode_map. Callers such as builtin-kmem.c:evsel__process_alloc_event() pass sample->cpu from perf.data events, which may exceed the host's CPU count when analyzing cross-machine recordings. Add a bounds check against max_cpu_num before indexing, returning -1 for out-of-range values. This is a central fix that protects all callers. Fixes: 86895b480a2f ("perf stat: Add --per-node agregation support") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bd027a461624f3b9a99ed07c5ad8ce5964174863 Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 18:11:41 2026 -0300 perf tools: Guard remaining test_bit calls from OOB sample CPU [ Upstream commit 7ccd2e6cecd5bb02a5a15f0dd7199d1e81380bda ] auxtrace.c:filter_cpu() and builtin-script.c:filter_cpu() call test_bit(cpu, cpu_bitmap) where cpu_bitmap is declared with MAX_NR_CPUS bits. When the CPU value from a perf.data event is corrupt or absent (e.g. negative or >= MAX_NR_CPUS), test_bit reads out of bounds. Add bounds checks before test_bit(): >= 0 for the int16_t cpu.cpu in auxtrace (which also covers the -1 sentinel), and < MAX_NR_CPUS for both sites. Matches the pattern applied in the previous series for builtin-annotate.c, builtin-diff.c, builtin-report.c, and builtin-sched.c. Fixes: 644e0840ad46 ("perf auxtrace: Add CPU filter support") Fixes: 5d67be97f890 ("perf report/annotate/script: Add option to specify a CPU range") Reported-by: sashiko-bot Cc: Adrian Hunter Cc: Anton Blanchard Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e94a56aac6b4457847247e88148b7caa20ca86fd Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 13:05:10 2026 -0300 perf sched: Fix comp_cpus heap overflow with cross-machine recordings [ Upstream commit c8b04142078a9ccb9e402ab7c38de7123256f4a5 ] setup_map_cpus() allocates comp_cpus based on sysconf(_SC_NPROCESSORS_CONF), the host machine's CPU count. But map_switch_event() indexes comp_cpus using cpus_nr derived from bitmap_weight(comp_cpus_mask, MAX_CPUS), where comp_cpus_mask is declared as DECLARE_BITMAP(..., MAX_CPUS) with MAX_CPUS=4096. When analyzing a perf.data recording from a machine with more CPUs than the analysis host (e.g. 128-CPU server recording analyzed on an 8-CPU laptop), cpus_nr exceeds the allocation size, causing a heap buffer overflow. Also fix a type mismatch: comp_cpus is 'struct perf_cpu *' (2 bytes per element) but was allocated with sizeof(int) (4 bytes per element). Allocate comp_cpus with MAX_CPUS entries using the correct element size, matching the comp_cpus_mask bitmap bounds. Remove the sysconf(_SC_NPROCESSORS_CONF) initialization of max_cpu — its only consumer was the comp_cpus allocation, and max_cpu is dynamically updated from the recording's events during processing. Fix the non-compact path to use max_cpu.cpu + 1 as cpus_nr, converting from 0-based index to count — sysconf() returned a count which masked this off-by-one. Fixes: 99623c628f54 ("perf sched: Add compact display option") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 70d31bdd3789c055b81585f09a72afd3b2cf1597 Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 12:56:02 2026 -0300 perf sched: Fix NULL dereference in latency_runtime_event [ Upstream commit 8cbca8a480e15f6326ce94287570993f27a4b2d5 ] latency_runtime_event() passes the return value of machine__findnew_thread() directly to thread_atoms_search() at line 1216, before checking for NULL at line 1220. thread_atoms_search() calls pid_cmp() which dereferences the thread pointer via thread__tid(), causing a NULL pointer dereference if the allocation fails. All other callers of thread_atoms_search() in this file (latency_switch_event, latency_wakeup_event, latency_migrate_task_event) correctly check for NULL first. Move the atoms assignment after the NULL check to match the pattern used by the other callers. Fixes: b91fc39f4ad7 ("perf machine: Protect the machine->threads with a rwlock") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bbaa0a0441d2638bd59923864f4b2cee9df6b8bf Author: Arnaldo Carvalho de Melo Date: Mon Jun 1 19:53:41 2026 -0300 perf sched: Replace BUG_ON on invalid CPU with graceful skip [ Upstream commit 1e2c83f732deb329ebce23e26cbc482f4c4bf194 ] latency_switch_event(), latency_runtime_event(), and map_switch_event() use BUG_ON(cpu >= MAX_CPUS || cpu < 0) to validate the sample CPU. When PERF_SAMPLE_CPU is absent from the sample type, evsel__parse_sample() initializes sample->cpu to (u32)-1. Casting this to int yields -1, which triggers the BUG_ON and aborts perf sched. The central CPU validation in perf_session__deliver_event() intentionally preserves the (u32)-1 sentinel for downstream tools like perf script and perf inject, so leaf callbacks must handle it themselves. Replace the three BUG_ON calls with graceful skips using pr_warning(), matching the existing pattern in process_sched_switch_event() and process_sched_runtime_event() earlier in the same file. Include the file offset for cross-referencing with perf report -D. Reported-by: sashiko-bot@kernel.org # Running on a local machine Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 8cbca8a480e1 ("perf sched: Fix NULL dereference in latency_runtime_event") Signed-off-by: Sasha Levin commit a4ec6bf241456acfc235bbc6981cdfcc3d420d1f Author: Arnaldo Carvalho de Melo Date: Mon Jun 1 13:07:52 2026 -0300 perf sample: Add file_offset field to struct perf_sample commit 7a490187f22b4bfae7ef752edbe3fb13017ca11c upstream. Add a file_offset field to struct perf_sample so that event processing callbacks can report the byte offset of the problematic event in perf.data, letting users cross-reference with 'perf report -D' output. Set sample.file_offset in perf_session__deliver_event(), which is the common entry point for both file mode (mmap'd offset) and pipe mode (running byte counter from __perf_session__process_pipe_events). The assignment is placed after evsel__parse_sample(), which zeroes the struct via memset. Preserve file_offset through the deferred callchain delivery path by storing it in struct deferred_event and restoring it after evlist__parse_sample() in both evlist__deliver_deferred_callchain() and session__flush_deferred_samples(). Subsequent patches will use this field in skip/stop warning messages. Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit b189fce8d2ac6928cd8ada8e1823cd9bf6f424de Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 12:55:29 2026 -0300 perf sched: Fix thread reference leak in latency_switch_event [ Upstream commit 66ea9de60396a4dea5276bc87025884691876c36 ] In latency_switch_event(), after acquiring thread references for sched_out and sched_in via machine__findnew_thread(), the first add_sched_out_event() failure path does 'return -1', bypassing the out_put label that calls thread__put() on both references. The second and third add_sched_out_event() failures correctly use 'goto out_put'. Fix the first one to match. Fixes: b91fc39f4ad7 ("perf machine: Protect the machine->threads with a rwlock") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d88a630bacfaa4ece35448b0b3f7247f0381b791 Author: Arnaldo Carvalho de Melo Date: Thu Jun 4 12:55:06 2026 -0300 perf tools: Guard test_bit from out-of-bounds sample CPU [ Upstream commit a5498ccf8079fc91c938f122ff9697b0c526b2fd ] When PERF_SAMPLE_CPU is absent from a perf.data file, sample->cpu is initialized to (u32)-1 by evsel__parse_sample(). Five call sites pass this value directly to test_bit(sample->cpu, cpu_bitmap), reading massively out of bounds past the DECLARE_BITMAP(..., MAX_NR_CPUS) allocation of 4096 bits. Add a sample->cpu >= MAX_NR_CPUS guard before each test_bit() call, matching the existing safe pattern in builtin-kwork.c. This catches both the (u32)-1 sentinel and any corrupted CPU value exceeding the bitmap size. Fixes: 5d67be97f890 ("perf report/annotate/script: Add option to specify a CPU range") Cc: Anton Blanchard Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 885bd036cbdf99f78913ab704bca41a3bbaf06f6 Author: James Clark Date: Mon Apr 20 12:52:17 2026 +0100 perf annotate: Fix crashes on empty annotate windows [ Upstream commit 74802634e4a7e556429417963a8cbda27dd8b4b3 ] Annotate can open with an empty window if the disassembly tool fails. After the linked change, the TUI started assuming there was a current annotation line and could assert or segfault in the seek, refresh, and source-toggle paths. Handle empty annotate windows explicitly: set the asm entry count before resetting the browser, return early when refreshing an empty list, and ignore source line toggle when there is no current annotation line. Fixes the following when opening an annotation: perf: ui/browser.c:125: ui_browser__list_head_seek: Assertion `pos != NULL' failed. Aborted Fixes: e201757f7a0a901e ("perf annotate: Fix source code annotate with objdump") Assisted-by: GitHub Copilot:GPT-5.4 Signed-off-by: James Clark Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 25b1f78ef3527e179c0f5b0239f65720c0e6dc51 Author: Rui Qi Date: Thu May 28 14:23:55 2026 +0800 perf: Fix off-by-one stack buffer overflow in kallsyms__parse() [ Upstream commit 68018df3f55eba96a20dd703f5f276a6518f4963 ] In kallsyms__parse(), the loop reading symbol names iterates with i < sizeof(symbol_name), which allows i to reach sizeof(symbol_name) upon loop exit. The subsequent symbol_name[i] = '\0' then writes one byte past the end of the stack-allocated symbol_name[] array. Fix this by changing the loop bound to KSYM_NAME_LEN, so the null terminator always lands within the array. The overflow is triggerable by a kallsyms entry with a symbol name of KSYM_NAME_LEN+1 or more characters (e.g., long Rust mangled names or a malicious /proc/kallsyms). Fixes: 53df2b9344128984 ("libsymbols kallsyms: Parse using io api") Signed-off-by: Rui Qi Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4442e8c8f20fec3ed580c3ff4fc100f207925c1b Author: Akhil R Date: Tue Mar 31 15:52:54 2026 +0530 dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional [ Upstream commit cc6049bd3fa8501ee27042df469a19ed69cf406d ] On Tegra264, GPCDMA reset control is not exposed to Linux and is handled by the boot firmware. Although reset was not exposed in Tegra234 as well, the firmware supported a dummy reset which just returns success on reset without doing an actual reset. This is also not supported in Tegra264 BPMP. Therefore mark 'reset' and 'reset-names' properties as required only for devices prior to Tegra264. This also necessitates that the Tegra264 compatible be standalone and cannot have the fallback compatible of Tegra186. Since there is no functional impact, we keep reset as required for Tegra234 to avoid breaking the ABI. Fixes: bb8c97571db5 ("dt-bindings: dma: Add Tegra264 compatible string") Signed-off-by: Akhil R Acked-by: Rob Herring (Arm) Acked-by: Thierry Reding Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260331102303.33181-2-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4e8f512e2b8fdf20641d9e6ead73bcd9a35b62d1 Author: Shengjiu Wang Date: Tue Apr 7 11:27:55 2026 +0800 dmaengine: imx-sdma: Refine spba bus searching in probe [ Upstream commit d52d42e2e5d9f13166e81ac837ebb023d1306e61 ] There are multi spba-busses for i.MX8M* platforms, if only search for the first spba-bus in DT, the found spba-bus may not the real bus of audio devices, which cause issue for sdma p2p case, as the sdma p2p script presently does not deal with the transactions involving two devices connected to the AIPS bus. Search the SDMA parent node first, which should be the AIPS bus, then search the child node whose compatible string is spba-bus under that AIPS bus for the above multi spba-busses case. Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support") Signed-off-by: Shengjiu Wang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260407032755.2758049-1-shengjiu.wang@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3ea71aa629a78b1aa9cb8e4704a86c4e0b9e02f9 Author: Xu Rao Date: Wed Jun 3 17:59:57 2026 +0800 thunderbolt: debugfs: Fix margining error counter buffer leak [ Upstream commit 503c5ae1e72aa9ed91925dafa3d82ee2e992747f ] When USB4 lane margining debugfs write support is enabled, margining_error_counter_write() copies the user input with validate_and_copy_from_user(). This allocates a temporary page that is only needed while parsing the requested error counter mode. The function currently returns without freeing that page. This leaks one page per write to the error_counter debugfs file, including successful writes and writes that later fail while taking the domain lock or because software margining is not enabled. Free the temporary page once parsing has completed, and also before returning from the invalid-input path. Fixes: 10904df3f20c ("thunderbolt: Improve software receiver lane margining") Signed-off-by: Xu Rao Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 994a42b890cef46cd576a3bf700f1dbd6bb21346 Author: Srinivasan Shanmugam Date: Mon Jun 1 19:42:15 2026 +0530 drm/amd/display: Add missing kdoc for ALLM parameters [ Upstream commit d4c6ec729fb7a8bf8a27b19bd70a1b945ad93dac ] Add descriptions for the missing parameters for ALLMEnabled and ALLMValue to keep the function documentation synchronized with the function prototype mod_build_hf_vsif_infopacket(). Fixes the below with gcc W=1: ../display/modules/info_packet/info_packet.c:507 function parameter 'ALLMEnabled' not described in 'mod_build_hf_vsif_infopacket' ../display/modules/info_packet/info_packet.c:507 function parameter 'ALLMValue' not described in 'mod_build_hf_vsif_infopacket' Fixes: 3c2381b92cba ("drm/amd/display: add support for VSIP info packet") Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Aurabindo Pillai Cc: Wayne Lin Cc: Nicholas Kazlauskas Cc: Bhawanpreet Lakha Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 668791009a218a46dfe89ee7054053eb10543e69 Author: Jamie Nguyen Date: Tue May 19 12:42:20 2026 -0700 fs/ntfs3: fix mount failure on 64K page-size kernels [ Upstream commit b7a9125cac8645245d2473c6c0a50e338280ad23 ] On 64K page-size kernels, mounting NTFS volumes smaller than ~650 MB fails with EINVAL. The issue is in log_replay(): the initial log page size probe uses PAGE_SIZE (65536) instead of DefaultLogPageSize (4096) when PAGE_SIZE exceeds DefaultLogPageSize * 2. This makes norm_file_page() require the $LogFile to be at least 50 * 65536 = 3.2 MB, but mkfs.ntfs creates a $LogFile of only ~1.5 MB for a typical 300 MB volume. norm_file_page() returns 0 and the mount is rejected with EINVAL. On 4K kernels the #if guard evaluates to true, so use_default=true is passed and DefaultLogPageSize (4096) is used, requiring only ~200 KB. This path works fine. Fix this by always passing use_default=true, which forces the initial probe to use DefaultLogPageSize regardless of the kernel's PAGE_SIZE. This is safe because, after reading the on-disk restart area, log_replay() already re-adjusts log->page_size to match the volume's actual sys_page_size. Also fix read_log_page() to pass log->page_size instead of PAGE_SIZE to ntfs_fix_post_read(), matching the actual buffer size. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Tested-by: Matthew R. Ochs Signed-off-by: Jamie Nguyen Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit bc95e2f611926bd321d8ac39b2bb451923d96593 Author: Arnd Bergmann Date: Fri May 15 11:09:50 2026 +0200 ntfs3: avoid another -Wmaybe-uninitialized warning [ Upstream commit 1bf15dd17385e3730521d17e9e158c475cd7474b ] The ntfs3 specific -Wmaybe-uninitialized flag found one more false-postive, this time with gcc-10 on s390: fs/ntfs3/frecord.c: In function 'ni_expand_list': fs/ntfs3/frecord.c:1370:16: error: 'ins_attr' may be used uninitialized in this function [-Werror=maybe-uninitialized] Add an explicit NULL pointer check before using the pointer, and initialize it to NULL. Fixes: 48d9b57b169f ("fs/ntfs3: add a subset of W=1 warnings for stricter checks") Signed-off-by: Arnd Bergmann Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 3cd2212012c06d2b1fd03a6bf84f6202ab70056c Author: Mihai Brodschi Date: Mon May 11 20:19:04 2026 +0300 ntfs3: Allocate iomap inline_data using alloc_page [ Upstream commit 70d3855594cf6e8791970714b65cac3202d6160e ] This fixes a BUG reported in iomap_write_end_inline: iomap_inline_data_valid checks that the inline_data fits within a page. If the inline_data is allocated with kmemdup there's no guarantee that it's page-aligned, so the check sometimes fails. Allocate it with alloc_page to ensure it's page-aligned. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221446 Fixes: 099ef9ab9203 ("fs/ntfs3: implement iomap-based file operations") Signed-off-by: Mihai Brodschi Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit ff825bf0521f6da2f30878cbad18ab7b341bc31b Author: Helen Koike Date: Wed May 6 14:08:22 2026 -0300 fs/ntfs3: call _ntfs_bad_inode() when failing to rename [ Upstream commit e8ed78f40eecd0176fda71d673f6957c98e7ffbe ] It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce ("fs/ntfs3: Exclude call make_bad_inode for live nodes.") The WARN_ON was added when it wasn't safe by: commit d99208b91933 ("fs/ntfs3: cancle set bad inode after removing name fails") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode. Reported-by: syzbot+4d8e30dbafb5c1260479@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4d8e30dbafb5c1260479 Fixes: 519b078998ce ("fs/ntfs3: Exclude call make_bad_inode for live nodes.") Signed-off-by: Helen Koike Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 1f6111ad30d2e967e7b8310e23d7647484ccd09c Author: Zhan Xusheng Date: Fri May 8 17:52:45 2026 +0800 fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run [ Upstream commit 36c7276816ed4266c155b71b1fa747b2785f23f7 ] When run_remove_range() removes a middle portion of a non-sparse run, it splits the run into head and tail parts. The tail is inserted via run_add_entry() but uses the original r->lcn as its starting LCN instead of advancing it by the split offset. For example, removing VCN range [10, 20) from a run {vcn=0, lcn=100, len=30} should produce: {vcn=0, lcn=100, len=10} (head) {vcn=20, lcn=120, len=10} (tail, lcn advanced by 20) But the current code produces: {vcn=0, lcn=100, len=10} {vcn=20, lcn=100, len=10} (wrong: points to same physical clusters) This creates overlapping physical mappings in the in-memory run tree, which can corrupt cluster allocation decisions and lead to data corruption. The correct pattern is already used in run_insert_range(): CLST lcn2 = r->lcn == SPARSE_LCN ? SPARSE_LCN : (r->lcn + len1); Apply the same logic in run_remove_range(). Fixes: 10d7c95af043 ("fs/ntfs3: add delayed-allocation (delalloc) support") Signed-off-by: Zhan Xusheng Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 41081202eb823f5b27ff164b12010b24428100ad Author: Konstantin Komarov Date: Thu Apr 30 14:30:13 2026 +0200 fs/ntfs3: add bounds check to run_get_highest_vcn() [ Upstream commit bb11485a87fbb2254b62cfed630b699d50e57da8 ] run_get_highest_vcn() parses a packed NTFS mapping-pairs buffer without any length bound, relying solely on a 0x00 terminator to stop. A crafted $LogFile UpdateMappingPairs record whose embedded attribute contains mapping-pairs runs without a terminator causes the function to read past the slab allocation, triggering a KASAN slab-out-of-bounds read on mount. The sibling function run_unpack() received an analogous bounds-check in commit b62567bca474 ("ntfs3: add buffer boundary checks to run_unpack()"), but run_get_highest_vcn() was missed. Take a run_buf_size parameter and reject any run header whose payload would extend past the buffer end, mirroring the pattern used by run_unpack(). The caller in fslog.c passes the remaining attribute bytes after the mapping-pairs offset. KASAN report (on mainline v7.1 merge window HEAD): BUG: KASAN: slab-out-of-bounds in run_get_highest_vcn+0x3c0/0x410 Read of size 1 at addr ffff88800e2d5400 by task mount/72 Call Trace: run_get_highest_vcn+0x3c0/0x410 do_action.isra.0+0x3ba8/0x7b50 log_replay+0x9ddd/0x10200 ntfs_loadlog_and_replay+0x4ad/0x610 ntfs_fill_super+0x214a/0x4540 Fixes: b62567bca474 ("ntfs3: add buffer boundary checks to run_unpack()") Signed-off-by: Jaeyeong Lee Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 3dcdf8ddb5093a09c53cf30843f117ca484c743d Author: Yixun Lan Date: Mon May 11 02:59:10 2026 +0000 clk: spacemit: k3: Fix PCIe clock register offset [ Upstream commit 2f20c859a82a291483a8b3f01cbfbb1642782a14 ] The offset of PCIe Clock CTRL register for port B and C controller was wrongly swapped, correct it here. Fixes: 091d19cc2401 ("clk: spacemit: k3: extract common header") Acked-by: Conor Dooley Link: https://patch.msgid.link/20260511-06-pci-clk-fix-v2-2-c9a5e563bab3@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 0b4739fc72dbcd4387198a245b249aa2eb3a9203 Author: Yixun Lan Date: Mon May 11 02:59:09 2026 +0000 clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock [ Upstream commit d8a4cef90b1a4ae9196a5bfba683eb9a0c75acdc ] According to SpacemiT updated docs, the PCIe master and slave clock's parent is the pll2_d6 clock, so fix it. Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Link: https://patch.msgid.link/20260511-06-pci-clk-fix-v2-1-c9a5e563bab3@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit d823ab4592b34ee00100d253260b43c8021b7732 Author: Zhan Xusheng Date: Tue May 26 10:20:33 2026 +0800 docs: changes.rst: restore pahole 1.26 minimum (regressed by sort) [ Upstream commit 2c1ccd9a1d786503086e83fe83e5c3b3c953b70e ] Commit 9edd04c4189e ("docs: Raise minimum pahole version to 1.26 for KF_IMPLICIT_ARGS kfuncs") raised the minimum required pahole version from 1.22 to 1.26 in the requirements table and added a paragraph explaining the failure mode for distributions still shipping pahole v1.25 (e.g. Ubuntu 24.04 LTS). The next day, commit ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists") came through a different tree (docs vs sched_ext) and re-flowed the table alphabetically, but its base did not include 9edd04c4189e. When the two commits met in mainline, the textual rewrite of the table won and the version bump was lost. The added "Since Linux 7.0..." paragraph also disappeared. The result is that changes.rst on master (v7.1-rc5) lists pahole 1.22 again, even though sched_ext kfuncs annotated with KF_IMPLICIT_ARGS genuinely require v1.26 to produce a correct vmlinux BTF. Users on distributions with pahole v1.25 hit "func_proto incompatible with vmlinux" when loading any sched_ext BPF program (scx_simple, scx_qmap, ...) and have no documentation pointing them at the version gap. Restore both changes from 9edd04c4189e. Fixes: ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists") Signed-off-by: Zhan Xusheng Signed-off-by: Jonathan Corbet Message-ID: <20260526022033.1301884-1-zhanxusheng@xiaomi.com> Signed-off-by: Sasha Levin commit 83d87cbfa3aa042c8fe61f93583687cf7af4d634 Author: Rosen Penev Date: Sat May 30 17:01:50 2026 -0700 HID: logitech-hidpp: remove excess kernel-doc member in hidpp_scroll_counter [ Upstream commit f22a5db8a7d38152556f230d6d68e59dbc27971b ] The @dev member described in the kernel-doc does not exist in the struct. Remove the stale entry. Fixes: 0610430e3dea ("HID: logitech-hidpp: add input_device ptr to struct hidpp_device") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit b7ef2eb239369c123bbac875a861c5e38892042c Author: Yuho Choi Date: Fri May 29 00:20:51 2026 -0400 clk: at91: keep securam node alive while mapping it [ Upstream commit 22fa1c39ba6fe726b547c877c924379b7fee260a ] pmc_register_ops() gets an owned reference to the "atmel,sama5d2-securam" node with of_find_compatible_node(). The success path dropped that reference before passing the node to of_iomap(), leaving of_iomap() to consume a node pointer after the caller had released its reference. Move of_node_put() after of_iomap() so the node remains referenced for the mapping operation. The unavailable-node error path already releases the reference. Fixes: 4d21be864092 ("clk: at91: pmc: execute suspend/resume only for backup mode") Signed-off-by: Yuho Choi Reviewed-by: Alexandre Belloni Link: https://patch.msgid.link/20260529042051.1626978-1-dbgh9129@gmail.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 8c00cabb19824fe108f83401117b356eaade97ec Author: Aldo Conte Date: Fri May 22 14:34:12 2026 +0200 iio: tcs3472: power down chip on probe failure [ Upstream commit b39f3bb9f5580d19bc0c10dea9224d75fed45f1d ] If tcs3472_probe() fails after enabling the chip (by writing PON | AEN to the ENABLE register), the error paths return without powering down the device. Add an 'error_powerdown' label at the end of the cleanup chain that calls tcs3472_powerdown() to power down the chip. The existing label cascade is rerouted to fall through to the new label. Move tcs3472_powerdown() above tcs3472_probe() so the probe can call it without a forward declaration. Found by code inspection while reviewing the probe error paths in preparation for the devm_ conversion. Fixes: eb869ade30a6 ("iio: Add tcs3472 color light sensor driver") Signed-off-by: Aldo Conte Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit f3d413e701c5e54bef736b638967724dda880365 Author: Sanjay Chitroda Date: Tue May 5 23:16:31 2026 +0530 iio: accel: mma8452: handle I2C read error(s) in mma8452_read() [ Upstream commit 5bdff291d20c31b365d9ddfe9c426fbfb41da5bb ] Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller. Fixes: 96c0cb2bbfe0 ("iio: mma8452: add support for runtime power management") Signed-off-by: Sanjay Chitroda Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3c374d33f1338dbb5676919c5194caa9c5aa1631 Author: Guilherme Ivo Bozi Date: Tue May 12 21:31:50 2026 -0300 iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling [ Upstream commit 947eb6f0a274f8b15a0248051a65b069effd5057 ] ams_event_to_channel() may return a pointer past the end of dev->channels when no matching scan_index is found. This can lead to invalid memory access in ams_handle_event(). Add a bounds check in ams_event_to_channel() and return NULL when no channel is found. Also guard the caller to safely handle this case. Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver") Signed-off-by: Guilherme Ivo Bozi Reviewed-by: Salih Erim Tested-by: Salih Erim Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fb27ebf81136e796c7b719303ef6fd7e1ae5d488 Author: Joshua Crofts Date: Fri May 15 12:28:23 2026 +0200 iio: magnetometer: ak8975: fix potential kernel stack memory leak [ Upstream commit a9a00d727b7bbc5e913a919530a9dd468935bf95 ] Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code. Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260513-ak8975-fix-v1-1-104ea605dd54%40gmail.com Signed-off-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7f167853ef3c04a1cf303bd743de303381ac1b60 Author: Joshua Crofts Date: Tue May 5 09:31:27 2026 +0200 iio: light: si1133: prevent race condition on timeout [ Upstream commit 8c50a95ceb230d17801758a9e41ffbbbe46f8b4d ] Sashiko reported a bug where the si1133_command exits on timeout without halting the sensor or masking the interrupt. If the sensor completes the command later, any subsequent command to the sensor will cause the IRQ handler to complete immediately, returning stale data to the driver all while the command hasn't finished yet, shifting all potential reads in the future. Fix this by masking the IRQ if wait_for_completion_timeout() fails. When initiating a new command, do a dummy read of the IRQ_STATUS register and turn the IRQ back on. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/message/20260428-si1133-checkup-v2-5-70ad14bfefe2%40gmail.com Assisted-by: gemini:gemini-3.1-pro-preview Signed-off-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2413ede67e398e2a3b953b8c7bb65f5ebfba631e Author: Joshua Crofts Date: Tue May 5 09:31:26 2026 +0200 iio: light: si1133: reset counter to prevent race condition [ Upstream commit 0a5f45ed2342aabae1e32c72558d15be28940a95 ] Sashiko reported a potential race condition happening when the driver returns an errno after a timeout in the si1133_command() function. The premature exit causes the hardware and software counters to become out of sync by not updating data->rsp_seq, therefore the internal hardware counter keeps incrementing. Fix this by adding a call to si1133_cmd_reset_counter() before returning from timeout. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/message/20260428-si1133-checkup-v2-5-70ad14bfefe2%40gmail.com Assisted-by: gemini:gemini-3.1-pro-preview Signed-off-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 8e8b52ad5ab500a52016b519ce54c1822b5951df Author: Arnaldo Carvalho de Melo Date: Sat May 2 14:41:46 2026 -0300 perf header: Validate bitmap size before allocating in do_read_bitmap() [ Upstream commit 3669697bda41c562d90eb38f54881cc02ef3d51c ] do_read_bitmap() reads a u64 bit count from the file and passes it to bitmap_zalloc() without checking it against the remaining section size. A crafted perf.data could trigger a large allocation that would only fail later when the per-element reads exceed section bounds. Additionally, bitmap_zalloc() takes an int parameter, so a crafted size with bits set above bit 31 (e.g. 0x100000040) would pass the section bounds check but truncate when passed to bitmap_zalloc(), allocating a much smaller buffer than the subsequent read loop expects. Reject size values that exceed INT_MAX, and check that the data needed (BITS_TO_U64(size) u64 values) fits in the remaining section before allocating. Switch from bitmap_zalloc() to calloc() of u64 units so the allocation size matches the u64 read/write granularity and avoids unsigned long vs u64 mismatch on 32-bit architectures. Fix do_write_bitmap() to use memcpy to read u64-sized chunks from the unsigned long bitmap, preventing out-of-bounds reads on 32-bit systems where sizeof(unsigned long) is 4 but the bitmap is stored in u64 units. Fix process_mem_topology() minimum section size: the check used nr * 2 * sizeof(u64) per node, but do_read_bitmap() reads an additional u64 for the bitmap size, so the minimum is 3 * sizeof(u64). Fix memory leak in process_mem_topology() error paths: replace free(nodes) with memory_node__delete_nodes() to free per-node bitmaps allocated by do_read_bitmap(). Currently used by process_mem_topology() for HEADER_MEM_TOPOLOGY. Fixes: a881fc56038a ("perf header: Sanity check HEADER_MEM_TOPOLOGY") Closes: https://lore.kernel.org/linux-perf-users/20260414224622.2AE69C19425@smtp.kernel.org/ Closes: https://lore.kernel.org/linux-perf-users/20260410223242.DD76FC19421@smtp.kernel.org/ Reported-by: sashiko-bot@kernel.org # Running on a local machine Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6-1m Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ea63c57eb2f1ebda5c7dfc0409eb89bb8dd56dd1 Author: Arnaldo Carvalho de Melo Date: Sat May 2 14:37:39 2026 -0300 perf header: Sanity check HEADER_EVENT_DESC attr.size before swap [ Upstream commit 944f65c8b8231d26d4db6be67bcb641142603cb4 ] read_event_desc() reads nre (event count), sz (attr size), and nr (IDs per event) from the file and uses them to control allocations and loops without validating them against the section size. A crafted perf.data could trigger large allocations or many loop iterations before __do_read() eventually rejects the reads. Add bounds checks in read_event_desc(): - Reject sz smaller than PERF_ATTR_SIZE_VER0. - Require at least one event (nre > 0). - Check that nre events fit in the remaining section, using the minimum per-event footprint of sz + sizeof(u32). - Pre-swap attr->size to native byte order, then reject values below PERF_ATTR_SIZE_VER0 or above sz before calling perf_event__attr_swap() to prevent heap out-of-bounds access. - Handle ABI0 (attr.size == 0): substitute PERF_ATTR_SIZE_VER0, and on native-endian files write the value back so free_event_desc() does not treat the zero as its end-of-array sentinel (it iterates while attr.size != 0). The swap path skips the write-back — perf_event__attr_swap() has its own ABI0 fallback that sets VER0 after swapping. - Check that nr IDs fit in the remaining section before allocating. Fixes: b30b61729246 ("perf tools: Fix a problem when opening old perf.data with different byte order") Reported-by: sashiko-bot@kernel.org # Running on a local machine Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Assisted-by: Claude:claude-opus-4.6-1m Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 27ca3f615c1a8b5aec79f8c4706cc1c06605745a Author: Zhan Xusheng Date: Tue May 26 10:21:06 2026 +0800 timers/migration: Update stale @online doc to @available [ Upstream commit 45a13ba52c82dbec9715222c51e629e85daa37d7 ] Commit 8312cab5ff47 ("timers/migration: Rename 'online' bit to 'available'") renamed the 'online' field of struct tmigr_cpu to 'available'. The kernel doc comment above the struct still describes the old field name. Update it to reflect the actual field name and use the 'available' wording in the description. Fixes: 8312cab5ff47 ("timers/migration: Rename 'online' bit to 'available'") Signed-off-by: Zhan Xusheng Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260526022106.1302279-1-zhanxusheng@xiaomi.com Signed-off-by: Sasha Levin commit d61e42f63a00ec2af96ebb2814c48030e1f867b0 Author: Shawn Guo Date: Sun Apr 19 17:39:34 2026 +0800 PCI: qcom: Disable ASPM L0s for SA8775P [ Upstream commit 29f692985819f4089f02a86e151a72f6d4cdd90d ] Due to a hardware issue, L0s is not properly supported by the PCIe controller on the SA8775p SoC. If enabled, the L0s to L0 transition triggers below correctable AER errors and may also affect link stability: pcieport 0000:00:00.0: PME: Signaling with IRQ 332 pcieport 0000:00:00.0: AER: enabled with IRQ 332 pcieport 0000:00:00.0: AER: Correctable error message received from 0000:01:00.0 pci 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) pci 0000:01:00.0: device [17cb:1103] error status/mask=00001000/0000e000 pci 0000:01:00.0: [12] Timeout pcieport 0000:00:00.0: AER: Multiple Correctable error message received from 0000:01:00.0 pcieport 0000:00:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) pcieport 0000:00:00.0: device [17cb:0115] error status/mask=00001000/0000e000 pcieport 0000:00:00.0: [12] Timeout Hence, disable L0s for the SA8775p SoC to allow it to properly function by sacrificing a little bit of power saving. Fixes: 58d0d3e032b3 ("PCI: qcom-ep: Add support for SA8775P SOC") Assisted-by: Claude:claude-4-6-sonnet Signed-off-by: Shawn Guo [mani: commit log, corrected fixes tag] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260419093934.1223027-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Sasha Levin commit c764d5092b92c558d579662bc8bae052bfb82106 Author: Athira Rajeev Date: Mon May 4 20:43:20 2026 +0530 powerpc tools perf: Initialize error code in auxtrace_record_init function [ Upstream commit 789d22d77879eabb042627f6627cdb62787bc142 ] perf trace record fails some cases in powerpc # perf test "perf trace record and replay" 128: perf trace record and replay : FAILED! # perf trace record sleep 1 # echo $? 32 This is happening because of non-zero err value from auxtrace_record__init() function. static int record__auxtrace_init(struct record *rec) { int err; if ((rec->opts.auxtrace_snapshot_opts || rec->opts.auxtrace_sample_opts) && record__threads_enabled(rec)) { pr_err("AUX area tracing options are not available in parallel streaming mode.\n"); return -EINVAL; } if (!rec->itr) { rec->itr = auxtrace_record__init(rec->evlist, &err); if (err) return err; } Here "int err" is not initialised. The code expects "err" to be set from auxtrace_record__init() function. Update auxtrace_record__init() in arch/powerpc/util/auxtrace.c to clear err value in the beginning. - Clear err value in beginning of function. Any fail later will set appropriate return code to err. - Even if we haven't found any event for auxtrace, perf record should continue for other events. NULL return will indicate that there is no auxtrace record initialized. - Not having "err" set here will affect monitoring of other events also because perf record will fail seeing random value in err. Set err to -EINVAL before invoking auxtrace_record__init() in builtin-record.c With the fix, # perf trace record sleep 1 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.033 MB perf.data (228 samples) ] Fixes: 1dbfaf94cf66ec4b ("perf powerpc: Add basic CONFIG_AUXTRACE support for VPA pmu on powerpc") Reviewed-by: Adrian Hunter Signed-off-by: Athira Rajeev Acked-by: Namhyung Kim Cc: Athira Rajeev Cc: Hari Bathini Cc: Ian Rogers Cc: Jiri Olsa Cc: linuxppc-dev@lists.ozlabs.org Cc: Madhavan Srinivasan Cc: Michael Petlan Cc: Shivani Nittor Cc: Tanushree Shah Cc: Tejas Manhas Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0e1db8dc462328d4256fd4d8e42c27ab982376c1 Author: Baruch Siach Date: Sun May 17 18:41:41 2026 +0300 docs: threat-model: add missing closing parenthesis [ Upstream commit 89f332c1ef348e260a885085cd7821d6d72db7ec ] Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug") Signed-off-by: Baruch Siach Acked-by: Willy Tarreau Signed-off-by: Jonathan Corbet Message-ID: Signed-off-by: Sasha Levin commit 789d1b0e111838f802f3260c78df0f3e3d854004 Author: Lad Prabhakar Date: Wed May 20 10:29:47 2026 +0100 clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid shadowing [ Upstream commit 1f10c4509649e7c5f6d5d3acccf3ef6fbb5cdd46 ] Rename the internal loop iterator variable in the for_each_mod_clock() macro from 'i' to '__i'. The current naming conflicts with local loop variables named 'i' inside code blocks that utilize the macro, triggering compiler warnings due to variable shadowing: drivers/clk/renesas/rzg2l-cpg.c:1494:36: warning: declaration of `i` shadows a previous local [-Wshadow] 1494 | for (unsigned int i = 0; i < clk->num_shared_mstop_clks; i++) Using a unique identifier for the macro-internal iterator resolves the shadowing warnings globally across all macro expansions. Fixes: 3fd4a8bb4b63 ("clk: renesas: rzg2l: Add macro to loop through module clocks") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260520092947.70596-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit f15a545f7518bc0942d14daff88f1ec38e816a7c Author: Hongling Zeng Date: Sun May 3 17:30:36 2026 +0800 gpib: cb7210: Fix region leak when request_irq fails [ Upstream commit 5ad28496055858166eb2268344c8fda2c26d3561 ] When request_irq() fails, the region allocated by request_region() is not released. Fix this by calling release_region() before returning. Smatch warning: drivers/gpib/cb7210/cb7210.c:1068 cb_isa_attach() warn: 'config->ibbase' from __request_region() not released on lines: 1064. Fixes: 82e3508046f9 ("staging: gpib: cb7210 console messaging cleanup") Signed-off-by: Hongling Zeng Link: https://patch.msgid.link/20260503093036.283546-1-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8b5f1d295dda8677e4545ce340053fcfa8b634c7 Author: Adam Crosser Date: Fri Apr 24 19:37:47 2026 +0700 gpib: fix double decrement of descriptor_busy in command_ioctl() [ Upstream commit c4faab452b3c1ada003d49c477609dd80523b9bf ] commit d1857f8296dc ("gpib: fix use-after-free in IO ioctl handlers") introduced a descriptor_busy reference counter to pin struct gpib_descriptor across IO ioctl operations. In command_ioctl(), the error path inside the loop decrements descriptor_busy and breaks, but execution then falls through to the unconditional decrement after the loop, underflowing the counter to -1. This re-enables the use-after-free that the original fix was meant to prevent: a concurrent close_dev_ioctl() sees descriptor_busy == 0 on an actively-used descriptor and frees it. Remove the early decrement from the error path. The post-loop decrement already handles all exit paths, matching the correct pattern used in read_ioctl() and write_ioctl(). Fixes: d1857f8296dc ("gpib: fix use-after-free in IO ioctl handlers") Reported-by: Ruikai Peng Signed-off-by: Adam Crosser Link: https://patch.msgid.link/20260424123750.855863-1-adam.r.crosser@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a41f0fbd77ae1b95bb9ed679429e6fd883a526e7 Author: Rafael J. Wysocki Date: Tue May 12 18:20:53 2026 +0200 sonypi: Check ACPI_COMPANION() against NULL at probe time [ Upstream commit 950f35211b85db26fc1aae67bf1e14ccef393a0a ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the sonypi driver. Fixes: 7e488b0af021 ("sonypi: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5087721.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 99a34d028293600afaa7176be04acd3cb86b0508 Author: Rafael J. Wysocki Date: Tue May 12 18:20:09 2026 +0200 hpet: Check ACPI_COMPANION() against NULL at probe time [ Upstream commit fa5e2952341b792b72d5410dbfcd0b2ac8046d2a ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the hpet driver. Fixes: 71f0a267346b ("hpet: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4750803.LvFx2qVVIh@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42223445607a9a5df3cb1c4729abfe3a5085e7ce Author: James Kim Date: Sun May 3 19:11:31 2026 +0900 char: tlclk: fix use-after-free in tlclk_cleanup() [ Upstream commit bbf003b7794d6ad6f939fdd29f1f1bde8ac554c1 ] This patch improves the module cleanup process in the tlclk driver to prevent potential use-after-free and race conditions. Currently, the file_operations structure does not specify the .owner field, which could allow the module to be unloaded while user-space processes are still interacting with the device. Additionally, the tlclk_cleanup() function frees the alarm_events memory before ensuring that blocked processes in the waitqueue are fully awakened and that the switchover_timer has completed. To address these cases, this patch: - Sets '.owner = THIS_MODULE' in tlclk_fops to safely defer module unloading while the device is in use. - Updates tlclk_cleanup() to explicitly wake up all blocked readers (wake_up_all), properly release hardware I/O regions, and safely delete the timer (timer_delete_sync) prior to freeing memory. Fixes: 1a80ba882730 ("[PATCH] Telecom Clock Driver for MPCBL0010 ATCA computer blade") Signed-off-by: James Kim Link: https://patch.msgid.link/20260503101131.64219-1-james010kim@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 49489a18afa55db2cb8c3685e07e22e7447dca72 Author: Dave Penkler Date: Sat Apr 11 12:20:25 2026 +0200 gpib: Fix inappropriate ioctl error return [ Upstream commit 70ea440324e8c1a10837f721352f5bd469c85007 ] The driver was returning -ENOTTY in the case the ioctl command was not recognised. Change it to -EBADRQC. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Dave Penkler Link: https://patch.msgid.link/20260411102025.2000-3-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ecdd8af41197c00ff8edc00664b06174ecb0f0a4 Author: Ravi Bangoria Date: Fri May 8 05:59:57 2026 +0000 perf test amd ibs: Fix incorrect kernel version check [ Upstream commit 0b97e92393a178765ee1ea01fe5087efece2c425 ] "AMD IBS sample period" unit test is getting skipped on kernel v7.x. Fix the kernel version >= v6.15 check. Fixes: 21fb366b2f457611 ("perf test amd: Skip amd-ibs-period test on kernel < v6.15") Signed-off-by: Ravi Bangoria Acked-by: Namhyung Kim Cc: Ananth Narayan Cc: Dapeng Mi Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Manali Shukla Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sandipan Das Cc: Santosh Shukla Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 684a58dd845e4ca510d8409d2daa5f0645b0b484 Author: Seungjin Bae Date: Mon May 18 18:49:02 2026 -0400 usb: host: max3421: Reject hub port requests for non-existent ports [ Upstream commit 11b5c101e2fd206104b05bc92554d356989423a8 ] The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. The `GetPortStatus` case correctly rejects requests with `index != 1`, since the virtual root hub has only a single port. However, the `ClearPortFeature` and `SetPortFeature` cases lack the same check. Fix this by extending the `index != 1` rejection to both cases, matching the existing behavior of `GetPortStatus`. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Suggested-by: Alan Stern Reviewed-by: Alan Stern Signed-off-by: Seungjin Bae Link: https://patch.msgid.link/20260518224901.1887013-3-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4da073d57176d8e1c2bca34febfbc81d2560c1a5 Author: Seungjin Bae Date: Mon May 18 18:49:00 2026 -0400 usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() [ Upstream commit cff06b03b530ae1fe8a13e93a7848f2130e00fb4 ] The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Signed-off-by: Seungjin Bae Link: https://patch.msgid.link/20260518224901.1887013-1-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7fc162453cfb7b8e93edb16287a84ba0130cac38 Author: Guangshuo Li Date: Sun May 17 19:12:18 2026 +0800 staging: most: video: avoid double free on video register failure [ Upstream commit 7cb1c5b32a2bfde961fff8d5204526b609bcb30a ] comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing. Fixes: eab231c0398a ("staging: most: v4l2-aim: remove unnecessary label err_vbi_dev") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260517111218.945796-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b1493c42183fc6b0ef2b05ca6f8c9bfea1b44393 Author: Ian Rogers Date: Mon May 18 15:43:25 2026 -0700 perf inject: Fix itrace branch stack synthesis [ Upstream commit daac18e7c42c012e289bfd310503f9417e4a9481 ] When using "perf inject --itrace=L" to synthesize branch stacks from AUX data, several issues caused failures with the generated file: 1. The synthesized samples were delivered without the PERF_SAMPLE_BRANCH_STACK flag if it was not in the original event's sample_type. Fixed by using sample_type | evsel->synth_sample_type in intel_pt_do_synth_pebs_sample. 2. Modifying evsel->core.attr.sample_type early in __cmd_inject caused parse failures for subsequent records in the input file. Fixed by moving this modification to just before writing the header. 3. perf_event__repipe_sample was narrowed to only synthesize samples when branch stack injection was requested, and restored the use of perf_inject__cut_auxtrace_sample as a fallback to preserve functionality. 4. Potential Heap Overflow in perf_event__repipe_sample: Addressed by adding a check that prints an error and returns -EFAULT if the calculated event size exceeds PERF_SAMPLE_MAX_SIZE. 5. Header vs Payload Mismatch in __cmd_inject: Addressed by narrowing the condition so that HEADER_BRANCH_STACK is only set in the file header if add_last_branch was true. 6. NULL Pointer Dereference in intel-pt.c: When branch stack injection is requested (add_last_branch is true) but last_branch is false (e.g., perf inject --itrace=L), ptq->last_branch was not allocated. However, PEBS branch stack synthesis (via synth_sample_type) still forced LBR handling in do_synth_pebs_sample(), dereferencing the NULL ptq->last_branch pointer. Guarding the dereference is not sufficient because downstream sample size calculation and synthesis strictly require a non-NULL branch_stack when the bit is set. Fixed by ensuring ptq->last_branch is allocated in intel_pt_alloc_queue() when add_last_branch is requested. 7. Modifying event attributes in perf_event__repipe_attr in-place caused SIGSEGV on read-only mmap buffers in file mode and downstream parser breakage in pipe mode. Fixed by processing the unmodified attribute first, returning immediately in non-pipe mode, and correctly synthesizing a new attribute event for pipe output using perf_event__synthesize_attr. Also: - Added a size validation check and integer underflow protection when parsing n_ids. - Prevented Trailing ID memory corruption by zero-initializing the local attr copy and safely copying using min_t(size_t, sizeof(attr), event->attr.attr.size). - Resolved ID array parsing mismatch downstream by expanding attr.size to sizeof(struct perf_event_attr) before synthesis to guarantee perfect header/attribute size alignment. 8. Potential dangling pointer vulnerability in perf_event__repipe_sample: Addressed by restoring the original sample->branch_stack pointer before returning, including on early error return paths. 9. Off-by-one error in sample size check in perf_event__repipe_sample: Fixed by checking if sz >= PERF_SAMPLE_MAX_SIZE instead of >. 10. Unadvertised size field left in payload by cut_auxtrace_sample: Addressed by excluding the 8-byte size field from the copied payload to correctly match the cleared PERF_SAMPLE_AUX bit. Cut the AUX sample payload even if size is 0. 11. Inaccurate sample size calculation and uninitialized memory leaks in convert_sample_callchain: Fixed by replacing manual arithmetic with perf_event__sample_event_size and adding a bounds check against PERF_SAMPLE_MAX_SIZE. 12. Omission of branch_sample_type in file headers: Addressed by expanding older, smaller attributes to PERF_ATTR_SIZE_VER2 in __cmd_inject to ensure branch_sample_type is not silently omitted. Fixes: 0f0aa5e0693ce400 ("perf inject: Add Instruction Tracing support") Assisted-by: Gemini:gemini-3.1-pro-preview Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Thomas Falcon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 034182b6310860858927b6daecc2f3b218c57c6e Author: Ian Rogers Date: Mon May 18 15:43:24 2026 -0700 perf event: Fix size of synthesized sample with branch stacks [ Upstream commit 059e9100d82aae2254f1b06835a55755936b1417 ] Synthesizing branch stacks for Intel-PT highlighted an issue where PERF_SAMPLE_BRANCH_HW_INDEX was assumed to always be set in the perf_event_attr branch_sample_type. This caused an incorrect size calculation. Fix the writing of the nr and hw_idx values during sample event synthesis by passing the branch_sample_type into the sample size and synthesis functions. Also update hardware tracers (Intel PT, ARM SPE, CS-ETM) to retrieve and pass their branch_sample_type dynamically to prevent payload misalignment. Fixes: d3f85437ad6a5511 ("perf evsel: Support PERF_SAMPLE_BRANCH_HW_INDEX") Assisted-by: Gemini:gemini-3.1-pro-preview Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Kan Liang Cc: Leo Yan Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Thomas Falcon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7e374ac7702bee491e8b1303b98effcf8b3fe2c6 Author: Michael Petlan Date: Wed May 20 00:38:55 2026 +0200 perf build-id: Fix off-by-one bug when printing kernel/module build-id [ Upstream commit 017bca78e4d72b1ff027d368c20a1b2c654edaf7 ] When changing sprintf functions to snprintf, one byte got lost. Since snprintf ones do not handle the '\0' terminating character, the number of printed characters is 40, while sizeof(sbuild_id) is 41, including the terminating '\0' character. This makes the later check fail so that nothing is printed. Fix that. Before: [Michael@Carbon ~]$ perf buildid-list -k [Michael@Carbon ~]$ After: [Michael@Carbon ~]$ perf buildid-list -k a527806324d543c4bc3ff2f9c9519d494fed5f68 [Michael@Carbon ~]$ Fixes: fccaaf6fbbc59910 ("perf build-id: Change sprintf functions to snprintf") Signed-off-by: Michael Petlan Tested-by: Ian Rogers Cc: Ian Rogers Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8b54808fcced126326a1d36d2398bfa9e5c9b205 Author: Conor Dooley Date: Thu Apr 30 19:30:28 2026 +0100 clk: microchip: mpfs-ccc: fix peripheral driver registration failures after oob fix [ Upstream commit c8a3be5bc2b2f2d53c56a8b9cab731e917b95c07 ] Commit 2f7ae8ab6aa73 ("clk: microchip: mpfs-ccc: fix out of bounds access during output registration") fixed the out of bounds access, but it did so by packing sparse indices into a linear space. When peripheral drivers request clocks, they obviously don't care for this compression and use the sparse indices, and therefore try to request the wrong clocks or clocks that don't exist. The most straightforward fix here seems to stop being clever with the packing and just overallocate the array. Fixes: 2f7ae8ab6aa73 ("clk: microchip: mpfs-ccc: fix out of bounds access during output registration") Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support") Reviewed-by: Brian Masney Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit b670ac2731ddfc802a89ce7151d1478715535250 Author: Rafael J. Wysocki Date: Mon May 11 22:03:34 2026 +0200 platform/x86: classmate-laptop: Address memory leaks on driver removal [ Upstream commit 4baf44b4051940ba1abc68ef5136d25cb1806521 ] Switch over cmpc_accel_add_v4() and cmpc_accel_add() to using devm_kzalloc() for allocating the accel object which will cause it to be freed automatically on device removal, so it won't be leaked any more. This also simplifies the rollback paths in these functions somewhat. Fixes: 529aa8cb0a59 ("classmate-laptop: add support for Classmate PC ACPI devices") Signed-off-by: Rafael J. Wysocki Acked-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/10846403.nUPlyArG6x@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ce5633204a4b1652a9191537e55b951425b32300 Author: Chen-Yu Tsai Date: Tue May 12 18:33:45 2026 +0800 PCI: mediatek-gen3: Fix incorrectly skipped pwrctrl error message [ Upstream commit 8ba433753d9b131c2e43b1ff7ba8c5730cef8231 ] When pwrctrl integration was added, the error message for pci_pwrctrl_create_devices() failure was incorrectly added after the goto statement, causing it to be skipped. Move the goto statement after the dev_err_probe() call so that the error message actually gets printed (or saved if probe is deferred). Fixes: 1a152e21940a ("PCI: mediatek-gen3: Integrate new pwrctrl API") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/adjNaKB5KGpl6qIp@stanley.mountain/ Signed-off-by: Chen-Yu Tsai Signed-off-by: Manivannan Sadhasivam Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260512103347.1751080-1-wenst@chromium.org Signed-off-by: Sasha Levin commit e31173a194662047fb929faaa55542e2b1387ebf Author: Dan Carpenter Date: Tue May 12 13:17:55 2026 +0300 PCI: dwc: Fix signedness bug in fault injection test code [ Upstream commit 94ac934d2c054fba4a22d8dc84749094c5fa0ec0 ] The kstrtou32() function returns negative error code or zero on success. However, in this case "val" is a u32 and the function returns signed long, so negative error codes from kstrtou32() are returned as high positive values. Store the error code in an int instead. Fixes: d20ee8e2dbd6 ("PCI: dwc: Add debugfs based Error Injection support for DWC") Signed-off-by: Dan Carpenter Signed-off-by: Manivannan Sadhasivam Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/agL-Uwfn26SI4Gb0@stanley.mountain Signed-off-by: Sasha Levin commit 8ca9adc805884d3bb5038082462577f86c2c4a10 Author: Jie Gan Date: Mon May 11 12:19:18 2026 +0800 coresight: platform: defer connection counter increment until alloc succeeds [ Upstream commit 1563ae33dc4f5ebac96b93af2ef72e72aaaa31ae ] coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path. Fixes: 3d4ff657e454 ("coresight: Dynamically add connections") Fixes: e3f4e68797a9 ("coresight: Store in-connections as well as out-connections") Signed-off-by: Jie Gan Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260511-fix-ref-count-issue-v1-1-99d647810d3c@oss.qualcomm.com Signed-off-by: Sasha Levin commit f344f6ae8517627efd891a8c0d33d4b6ce193b8d Author: Bartosz Golaszewski Date: Mon May 18 12:07:00 2026 +0200 PCI/pwrctrl: Lock device when calling device_is_bound() [ Upstream commit 548f3d287d92bcbc908b02db57fb889f8a8276a0 ] The kerneldoc for device_is_bound() states that it must be called with the device lock taken. Synchronize the two calls in pwrctrl core. Fixes: b35cf3b6aa1e ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices") Signed-off-by: Bartosz Golaszewski Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260518100700.47581-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Sasha Levin commit ac8a86dcaf59cd30cc37efb64149b4475fb1f9d9 Author: Wolfram Sang Date: Wed May 6 09:09:47 2026 +0200 mailbox: don't free the channel if the startup callback failed [ Upstream commit 4f176444dcc977d1888fd9220c357a4d32338ee0 ] If the optional startup() callbacks fails, we need to clear some states. Currently, this is done by freeing the channel. This does, however, more than needed which creates problems. Namely, it is calling the shutdown() callback. This is totally not intuitive. No user expects that shutdown() is called when startup() fails, similar to remove() not being called when probe() fails. Currently, quite some mailbox users register the IRQ in startup() and free them in shutdown(). These drivers will get a WARN about freeing an already free IRQ. Other subtle issues could arise from this unexpected behaviour. To solve this problem, introduce a helper which does the minimal cleanup and use it in both, in free_channel() and after startup() failed. Link: https://sashiko.dev/#/patchset/20260402112709.13002-1-wsa%2Brenesas%40sang-engineering.com # second issue Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 25d6ea6c76e1b1b7c57337b2f8f1b6fc8d5c52bc Author: Sergey Senozhatsky Date: Tue Apr 28 11:55:44 2026 +0900 mailbox: mtk-adsp: fix UAF during device teardown [ Upstream commit b57d1a40bc43258372fa1f4d39305e093947a262 ] When the SOF audio driver fails to initialize (e.g. firmware boot timeout), its devres unwind frees the snd_sof_dev object that the mailbox client (mtk-adsp-ipc) reaches via chan->cl->rx_callback. The mtk-adsp-mailbox shutdown clears the mailbox command registers but leaves the IRQ line unmasked, so a late interrupt can still queue a threaded handler after mbox_free_channel() had cleared chan->cl, and mbox_chan_received_data() would then trigger UAF: BUG: KASAN: slab-use-after-free in sof_ipc3_validate_fw_version sof_ipc3_validate_fw_version sof_ipc3_do_rx_work sof_ipc3_rx_msg mt8196_dsp_handle_request mtk_adsp_ipc_recv mbox_chan_received_data mtk_adsp_mbox_isr irq_thread_fn Freed by task ...: kfree devres_release_all really_probe ... (sof-audio-of-mt8196 probe failure) The crash was observed roughly three seconds after the failed probe. disable_irq() in shutdown and enable_irq() in startup. disable_irq() also waits for any in-flight interrupts, so by the time mbox_free_channel() proceeds to clear chan->cl no rx_callback can run. In addition, request the IRQ with IRQF_NO_AUTOEN so it stays masked between probe and the first client bind — otherwise an early interrupt can crash on chan->cl == NULL in mbox_chan_received_data(). Fixes: af2dfa96c52d ("mailbox: mediatek: add support for adsp mailbox controller") Signed-off-by: Sergey Senozhatsky Reviewed-by: Tzung-Bi Shih Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 8ceeb0541978dbafdc5f3c98ff8bbe0be713b8c6 Author: Conor Dooley Date: Thu May 14 17:39:51 2026 +0100 mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr() [ Upstream commit e30d8b2730a33e5e8789371e947c3529789a6070 ] mpfs_mbox_inbox_isr() writes to the sysreg scb syscon, not the control scb syscon, but checks for the presence of the latter. Ultimately this makes little difference because if one syscon is present, both will be. Fixes: a4123ffab9ece ("mailbox: mpfs: support new, syscon based, devicetree configuration") Signed-off-by: Conor Dooley Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 80cf6501acb9766778e2518a921ccae2c7c46924 Author: Chen-Yu Tsai Date: Tue May 5 18:59:16 2026 +0800 PCI: mediatek-gen3: Do full device power down on removal [ Upstream commit d39d55d7411c18ca6aeb63aafa8035f4ad8b317f ] When power control for downstream devices was introduced in the mediatek-gen3 PCIe controller driver, only the power to the downstream devices was cut when the controller driver is removed. This matched existing behavior, but in hindsight a proper power down sequence should have been followed. Call mtk_pcie_devices_power_down() on driver removal so that in addition to removing power from the downstream devices, PERST# is asserted. Fixes: 1a152e21940a ("PCI: mediatek-gen3: Integrate new pwrctrl API") Signed-off-by: Chen-Yu Tsai Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260505105918.1823170-1-wenst@chromium.org Signed-off-by: Sasha Levin commit 8c1dac9c05d489decb7db9b5e90573727a15354a Author: Leo Yan Date: Fri May 15 21:08:09 2026 +0100 coresight: Handle helper enable failure properly [ Upstream commit 864754d0a084141085f154db044401fb2dce6a34 ] If a helper fails to be enabled, unwind any helpers that were already enabled earlier in the loop. This avoids leaving partially enabled helpers behind. Fixes: 6148652807ba ("coresight: Enable and disable helper devices adjacent to the path") Reviewed-by: Yeoreum Yun Reviewed-by: James Clark Tested-by: James Clark Tested-by: Jie Gan Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260515-arm_coresight_path_power_management_improvement-v14-2-f88c4a3ecfe9@arm.com Signed-off-by: Sasha Levin commit c37f87151990dc079560b98ebe3b00a067b4953c Author: Jie Gan Date: Fri May 15 21:08:08 2026 +0100 coresight: Fix source not disabled on idr_alloc_u32 failure [ Upstream commit ea2c2b9e2a66e2b4aa0455b2d70058e2f0ea4d23 ] In coresight_enable_sysfs(), for non-CPU sources (SOFTWARE, TPDM, OTHERS), the source device is enabled via coresight_enable_source_sysfs() before idr_alloc_u32() maps the path. If idr_alloc_u32() fails, the original code jumped directly to err_source, which only calls coresight_disable_path() and coresight_release_path(). The source device was left enabled with an incremented refcnt but no path tracked for it, leaving the device in an inconsistent state. Disable the source before jumping to err_source so the enable and path operations are fully unwound. Fixes: 5c0016d7b343 ("coresight: core: Use IDR for non-cpu bound sources' paths.") Signed-off-by: Jie Gan Reviewed-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260515-arm_coresight_path_power_management_improvement-v14-1-f88c4a3ecfe9@arm.com Signed-off-by: Sasha Levin commit 81ed540159efd744c9fa4dd99039ecf788b8922f Author: Bard Liao Date: Thu May 14 22:16:25 2026 +0800 soundwire: intel_ace2x: release bpt_stream when close it [ Upstream commit 8a7fe10eec64bfb7cf4091bca540de4c55d56bfa ] The BPT stream was allocated in intel_ace2x_bpt_open_stream(), we need to free it in intel_ace2x_bpt_close_stream(). Fixes: 4c1ce9f37d8a8 ("soundwire: intel_ace2x: add BPT send_async/wait callbacks") Signed-off-by: Bard Liao Reviewed-by: Simon Trimmer Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260514141625.1834216-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit abdfdb8e6220ab9ec50822ba5f5416f2d674668a Author: Rafael J. Wysocki Date: Tue May 12 18:28:26 2026 +0200 iio: light: acpi-als: Check ACPI_COMPANION() against NULL [ Upstream commit ff29241030eb6f4505d903d87c29f51c1866a95d ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the acpi-als IIO driver. Fixes: d4243cb08a27 ("iio: light: acpi-als: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 14622b111e4e16c9066597a1d08c3fa55d81c14d Author: Mihai Sain Date: Mon Mar 9 09:53:28 2026 +0200 clk: at91: sam9x7: Fix gmac_gclk clock definition [ Upstream commit b6f6ebb0fb57ae6da622fb8fd4ebdc9ba1ae5756 ] According to the datasheet (see link section), table 12.1, instance ID 24 is used for the GMAC generic clock, while instance ID 67 is reserved. Add the correct gmac_gclk entry at ID 24, aligned with the SoC clock layout, and remove the old misplaced entry at ID 67. Link: https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X75-SIP-Series-Data-Sheet-DS60001827.pdf Fixes: 33013b43e271 ("clk: at91: sam9x7: add sam9x7 pmc driver") Signed-off-by: Mihai Sain Link: https://lore.kernel.org/r/20260309075329.1528-4-mihai.sain@microchip.com [claudiu.beznea: massaged the patch description] Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 8a7a8ac82791d218600dffa3fabbe7cf37b452ba Author: Leo Yan Date: Fri Apr 10 12:13:44 2026 +0100 perf pmu: Skip test on Arm64 when #slots is zero [ Upstream commit 2e2ba7d1ea554ee6e9e751a53eebf3e9270b0670 ] Some Arm64 PMUs expose 'caps/slots' as 0 when the slot count is not implemented, tool_pmu__read_event() currently returns false for this, so metrics that reference #slots are reported as syntax error. Since the commit 3a61fd866ef9 ("perf expr: Return -EINVAL for syntax error in expr__find_ids()"), these syntax errors are populated as failures and make the PMU metric test fail: 9.3: Parsing of PMU event table metrics: --- start --- ... Found metric 'backend_bound' metric expr 100 * (stall_slot_backend / (#slots * cpu_cycles)) for backend_bound parsing metric: 100 * (stall_slot_backend / (#slots * cpu_cycles)) Failure to read '#slots' literal: #slots = nan syntax error Fail to parse metric or group `backend_bound' ... ---- end(-1) ---- 9.3: Parsing of PMU event table metrics : FAILED! This commit introduces a new function is_expected_broken_metric() to identify broken metrics, and treats metrics containing "#slots" as expected broken when #slots == 0 on Arm64 platforms. Fixes: 3a61fd866ef9aaa1 ("perf expr: Return -EINVAL for syntax error in expr__find_ids()") Reviewed-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 03dda04f2f768ad620eee20fec1e04068330d483 Author: Ian Rogers Date: Wed May 13 16:31:45 2026 -0700 perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection [ Upstream commit 4248ae6e799605b3e62855be6085935d89de50d1 ] Currently, both libdw and libunwind define 'unwind__get_entries'. This causes a duplicate symbol build failure when both are compiled into perf. This commit refactors the DWARF unwind post-processing to be configurable at runtime via the .perfconfig file option 'unwind.style', or using the argument '--unwind-style' in the commands 'perf report', 'perf script' and 'perf inject', in a similar manner to the addr2line or the disassembler style. The file 'tools/perf/util/unwind.c' adds the top-level dispatch function 'unwind__get_entries'. The backend implementations are renamed to 'libdw__get_entries' and 'libunwind__get_entries'. Both are attempted as fallbacks if not configured, or if the primary backend fails. Fixes: 2e9191573a69ff96 ("perf build: Remove NO_LIBDW_DWARF_UNWIND option") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Andrew Jones Cc: Athira Rajeev Cc: Dapeng Mi Cc: Dmitrii Dolgov <9erthalion6@gmail.com> Cc: Florian Fainelli Cc: Howard Chu Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Leo Yan Cc: libunwind-devel@nongnu.org Cc: Li Guan Cc: Namhyung Kim Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Shimin Guo Cc: Thomas Richter Cc: Tomas Glozar Cc: Will Deacon [ Don't mix declarations and code, move 'entries' variable to the start of scope ] [ Use pr_warning_once() instead of pr_err() in stubs for get_entries(), suggested by a local sashiko instance ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9810f833df66fc3f7afcff667155344177b46f7f Author: Ian Rogers Date: Tue Apr 14 10:58:55 2026 -0700 perf pmu-events AMD: Switch l2_itlb_misses to bp_l1_tlb_miss_l2_tlb_miss.all [ Upstream commit 41a543c86d110073275e5294852d692e5faf6b3b ] l2_itlb_misses is a valid legacy cache event name, hence allowing it in all_events in metric.py. l2_itlb_misses was also a json event for AMD zen1, zen2 and zen3. For zen4, zen5 and zen6 the checking that metric events are within the json was skipping l2_itlb_misses as it is a valid legacy event, however, the PMU driver lacks the event mapping causing it to be a bad event when used in the metric. Add bp_l1_tlb_miss_l2_tlb_miss.all as the l2 itlb miss event (bp = branch predictor, the AMD way to say itlb), so that is used in preference to l2_itlb_misses when the event exists. Remove l2_itlb_misses from metric.py as the legacy event isn't used by any metrics and having it is error prone for newer AMD zen models. Fixes: e596f329668ec2b5 ("perf jevents: Add itlb metric group for AMD") Reviewed-by: Sandipan Das Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit cb329b1fa702ece1bb0c5638c5eb715c5476d0a8 Author: Andy Shevchenko Date: Thu May 14 00:01:26 2026 +0200 phy: phy-can-transceiver: Check driver match and driver data against NULL [ Upstream commit ebee9004cc0200b2b708ebf7ac625d35c71c049f ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override() so platform drivers that rely on the existence of a device's driver data need to verify its presence. Accordingly, add requisite match and driver data checks against NULL to the driver where they are missing. Fixes: a4a86d273ff1 ("phy: phy-can-transceiver: Add support for generic CAN transceiver driver") Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260513220336.369628-2-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0ba6fd199192e4f564df3e7217c90d5bfc44d2b2 Author: Qiang Yu Date: Thu Apr 16 21:16:25 2026 -0700 PCI: qcom: Set max OPP before DBI access during resume [ Upstream commit 5dc31cd4a91a7f006d23efa97a5594a7e3ac7790 ] During resume, qcom_pcie_icc_opp_update() may access DBI registers before the OPP votes are restored, triggering NoC errors. Set the PCIe controller to the maximum OPP first in resume_noirq(), then proceed with link/DBI accesses. The OPP is later updated again based on the actual link bandwidth requirements. Introduce a helper to reuse the max-OPP setup code and share it with probe(). Fixes: 5b6272e0efd5 ("PCI: qcom: Add OPP support to scale performance") Signed-off-by: Qiang Yu [mani: commit log and error log rewording] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260416-setmaxopp-v1-1-6a74e2d945a0@oss.qualcomm.com Signed-off-by: Sasha Levin commit 72a7bfee9fe8f067c73b3a53c6973a5cc8c4ce2c Author: Manikanta Maddireddy Date: Fri Apr 10 11:55:07 2026 +0530 PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a [ Upstream commit 1e1b554c2b910591aa3fffdb8077a2ca33bf3cb2 ] The ECRC (TLP digest) workaround was originally applied only for DesignWare core version 4.90a. Per discussion in Synopsys case, the dependency of the iATU TD bit on ECRC generation was removed in 5.10a, so apply the workaround for all DWC versions below that release. Replace the misleading comment that referred to raw version constants with readable DesignWare release name to help readability. Fixes: b210b1595606 ("PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well") Signed-off-by: Manikanta Maddireddy [mani: corrected fixes tag format] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260410062507.657453-1-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit f478709f7be8a5f3200b24f4fd735e95d222b1b4 Author: Biswapriyo Nath Date: Mon Mar 30 10:13:49 2026 +0000 dt-bindings: clock: qcom,sm6125-dispcc: reference qcom,gcc.yaml [ Upstream commit dbabf6a32ffb69a604f966ec01a20a060836939d ] Just like most of Qualcomm clock controllers, we can reference common qcom,gcc.yaml schema to unify the common parts of the binding. This also adds the '#reset-cells' property which is permitted for the SM6125 SoC clock controllers, but not listed as a valid property. Fixes: bb4d28e377cf ("arm64: dts: qcom: sm6125: Add missing MDSS core reset") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603150629.GYoouFwZ-lkp@intel.com/ Signed-off-by: Biswapriyo Nath Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260330-ginkgo-add-usb-ir-vib-v3-2-c4b778b0d7f8@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6c7f2108af205d090b18d3cc5a33bb5e71dd6ce2 Author: Luo Jie Date: Tue Jan 6 21:35:10 2026 -0800 clk: qcom: cmnpll: Account for reference clock divider [ Upstream commit 88c543fff756450bcd04ec4560c4440be36c9e75 ] The clk_cmn_pll_recalc_rate() function must account for the reference clock divider programmed in CMN_PLL_REFCLK_CONFIG. Without this fix, platforms with a reference divider other than 1 calculate incorrect CMN PLL rates. For example, on IPQ5332 where the reference divider is 2, the computed rate becomes twice the actual output. Read CMN_PLL_REFCLK_DIV and divide the parent rate by this value before applying the 2 * FACTOR scaling. This yields the correct rate calculation: rate = (parent_rate / ref_div) * 2 * factor. Maintain backward compatibility with earlier platforms (e.g. IPQ9574, IPQ5424, IPQ5018) that use ref_div = 1. Fixes: f81715a4c87c ("clk: qcom: Add CMN PLL clock controller driver for IPQ SoC") Signed-off-by: Luo Jie Reviewed-by: Konrad Dybcio Tested-by: George Moussalem Link: https://lore.kernel.org/r/20260106-qcom_ipq5332_cmnpll-v2-1-f9f7e4efbd79@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d1da8fcb88024f0bb721a6b4aedb0970928f9164 Author: Jie Gan Date: Tue May 12 09:56:07 2026 +0800 coresight: fix missing error code when trace ID is invalid [ Upstream commit f4526ffee6ff9f5845b430957417149eded74bf3 ] When coresight_path_assign_trace_id() cannot assign a valid trace ID, coresight_enable_sysfs() takes the err_path goto with ret still 0, returning success to the caller despite no trace session being started. Change coresight_path_assign_trace_id() to return int, moving the IS_VALID_CS_TRACE_ID() check inside it so it returns -EINVAL on failure and 0 on success. Update both callers to propagate this return value directly instead of inspecting path->trace_id after the call. Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path") Reviewed-by: James Clark Reviewed-by: Richard Cheng Signed-off-by: Jie Gan Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260512-fix-trace-id-error-v4-1-eb3de789767a@oss.qualcomm.com Signed-off-by: Sasha Levin commit adec0b0df4e24950924410ef9dcf892d6e3b7973 Author: Sumit Kumar Date: Tue Apr 14 11:59:41 2026 +0530 bus: mhi: ep: Add missing state_lock protection for mhi_state access [ Upstream commit ce3e534ee9c8d13a68c8a611c3b7bd0c2152d2ab ] The mhi_cntrl->mhi_state field should be protected by state_lock to ensure atomic state transitions. However, mhi_ep_power_up() access mhi_state without holding this lock, which can race with concurrent state transitions and lead to state corruption. Add proper state_lock protection around mhi_state access. Fixes: fb3a26b7e8af ("bus: mhi: ep: Add support for powering up the MHI endpoint stack") Fixes: f7d0806bdb1b3 ("bus: mhi: ep: Add support for handling SYS_ERR condition") Signed-off-by: Sumit Kumar Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260414-reset_worker_deadlock-v2-2-42fd682b45db@oss.qualcomm.com Signed-off-by: Sasha Levin commit e30fa2246972ebc6492e282d161349ba7f6e9094 Author: Sumit Kumar Date: Tue Apr 14 11:59:40 2026 +0530 bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker() [ Upstream commit 9dece4435d396e9877e27483552b910ba8654169 ] There is a potential deadlock scenario in mhi_ep_reset_worker() where the state_lock mutex is acquired twice in the same call chain: mhi_ep_reset_worker() mutex_lock(&mhi_cntrl->state_lock) mhi_ep_power_up() mhi_ep_set_ready_state() mutex_lock(&mhi_cntrl->state_lock) <- Deadlock Fix this by releasing the state_lock before calling mhi_ep_power_up(). The lock is only needed to protect current MHI state read operation. The lock can be safely released before proceeding with the power up sequence. Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET") Signed-off-by: Sumit Kumar Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260414-reset_worker_deadlock-v2-1-42fd682b45db@oss.qualcomm.com Signed-off-by: Sasha Levin commit 34b2a1076dd71b979e60056721e0811fcdcd1800 Author: Hsiu Che Yu Date: Mon Apr 27 22:15:49 2026 +0800 rust: alloc: fix assert in `Vec::reserve` doc test [ Upstream commit 75619f2df7a5da6ffb61eedc2a73fdf70c65471c ] The assert in the doctest used `>= 10`, which only checks that the capacity can hold `additional` elements, ignoring the existing length of `v`. The correct check should ensure there is room for `additional` *extra* elements on top of what is already in the vector. Fix the assert to use `>= v.len() + 10` so the example accurately reflects the actual semantics of the function. Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/rust-for-linux/CANiq72nkXWhjK9iFRrhGtkMZGsvNE_zVsu4JnxaFRfxWL7RRdg@mail.gmail.com/ Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type") Signed-off-by: Hsiu Che Yu Reviewed-by: Alice Ryhl Reviewed-by: Alexandre Courbot Link: https://patch.msgid.link/20260427-doctest-kvec-reserve-v1-1-0623abcd9c2e@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 1f95260a82374648888b2fdae50a98f1b1978741 Author: Rong Zhang Date: Fri May 1 02:45:23 2026 +0800 PCI: loongson: Do not ignore downstream devices on external bridges [ Upstream commit 1389ab9bf9f627d4daed86f492091b00f110aa86 ] Loongson PCI host controllers have a hardware quirk that requires software to ignore downstream devices with device number > 0 on the internal bridges. The current implementation applies the workaround to all non-root buses, which breaks external bridges (e.g., PCIe switches) with multiple downstream devices. Fix it by only applying the workaround to internal bridges. Tested on Loongson-LS3A4000-7A1000-NUC-SE, using AMD Promontory 21 chipset add-in card [1]. $ lspci -tnnnvvv -[0000:00]-+-00.0 Loongson Technology LLC 7A1000 Chipset Hyper Transport Bridge Controller [0014:7a00] +-00.1 Loongson Technology LLC 7A2000 Chipset Hyper Transport Bridge Controller [0014:7a10] +-03.0 Loongson Technology LLC 2K1000/2000 / 7A1000 Chipset Gigabit Ethernet Controller [0014:7a03] +-04.0 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB OHCI Controller [0014:7a24] +-04.1 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB EHCI Controller [0014:7a14] +-05.0 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB OHCI Controller [0014:7a24] +-05.1 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB EHCI Controller [0014:7a14] +-06.0 Loongson Technology LLC 7A1000 Chipset Vivante GC1000 GPU [0014:7a15] +-06.1 Loongson Technology LLC 2K1000 / 7A1000 Chipset Display Controller [0014:7a06] +-07.0 Loongson Technology LLC 2K1000/2000/3000 / 3B6000M / 7A1000/2000 Chipset HD Audio Controller [0014:7a07] +-08.0 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-08.1 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-08.2 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-09.0-[01]----00.0 Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103] +-0a.0-[02]----00.0 Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller [1b6f:7052] +-0f.0-[03-08]----00.0-[04-08]--+-00.0-[05]----00.0 Shenzhen Longsys Electronics Co., Ltd. FORESEE XP1000 / Lexar Professional CFexpress Type B Gold series, NM620 PCIe NVME SSD (DRAM-less) [1d97:5216] | +-08.0-[06]----00.0 MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) [1e4b:1202] | +-0c.0-[07]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset USB 3.2 Controller [1022:43f7] | \-0d.0-[08]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller [1022:43f6] \-16.0 Loongson Technology LLC 7A1000 Chipset SPI Controller [0014:7a0b] Fixes: 2410e3301fcc ("PCI: loongson: Don't access non-existent devices") Co-developed-by: Jiaxun Yang Signed-off-by: Jiaxun Yang Co-developed-by: Lain "Fearyncess" Yang Signed-off-by: Lain "Fearyncess" Yang Signed-off-by: Rong Zhang Signed-off-by: Manivannan Sadhasivam Link: https://oshwhub.com/wesd/b650 [1] Link: https://patch.msgid.link/20260501-ls7a-bridge-fixes-v2-1-69fa93683805@rong.moe Signed-off-by: Sasha Levin commit f62ffd973b07fffe22fc3689e08b39f9a1adc845 Author: Florian Eckert Date: Fri Apr 17 10:35:49 2026 +0200 PCI: intel-gw: Add .start_link() callback [ Upstream commit 1eedabe7c6170b5c73c7d801f427c127be74916e ] The pcie-intel-gw driver had no .start_link() callback. Add one so the driver works again and does not abort with the following error messages during probing: intel-gw-pcie d1000000.pcie: host bridge /soc/pcie@d1000000 ranges: intel-gw-pcie d1000000.pcie: MEM 0x00dc000000..0x00ddffffff -> 0x00dc000000 intel-combo-phy d0c00000.combo-phy: Set combo mode: combophy[1]: mode: PCIe single lane mode intel-gw-pcie d1000000.pcie: No outbound iATU found intel-gw-pcie d1000000.pcie: Cannot initialize host intel-gw-pcie d1000000.pcie: probe with driver intel-gw-pcie failed with error -22 intel-gw-pcie c1100000.pcie: host bridge /soc/pcie@c1100000 ranges: intel-gw-pcie c1100000.pcie: MEM 0x00ce000000..0x00cfffffff -> 0x00ce000000 intel-combo-phy c0c00000.combo-phy: Set combo mode: combophy[3]: mode: PCIe single lane mode intel-gw-pcie c1100000.pcie: No outbound iATU found intel-gw-pcie c1100000.pcie: Cannot initialize host intel-gw-pcie c1100000.pcie: probe with driver intel-gw-pcie failed with error -22 Fixes: c5097b9869a1 ("Revert "PCI: dwc: Wait for link up only if link is started"") Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") Signed-off-by: Florian Eckert Signed-off-by: Manivannan Sadhasivam [bhelgaas: remove timestamps] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-5-0a2b933fe04f@dev.tdt.de Signed-off-by: Sasha Levin commit b2dd40f1d15efcf435403307fa60e049c849c7d0 Author: Florian Eckert Date: Fri Apr 17 10:35:48 2026 +0200 PCI: intel-gw: Enable clock before PHY init [ Upstream commit febf9ed3c35e5eec7ea384ebbd55a5296e3ca5e9 ] To ensure that the boot sequence is correct, the DWC PCIe core clock must be switched on before PHY init call [1]. This changes are based on patched kernel sources of the MaxLinear SDK. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de Stable-dep-of: 1eedabe7c617 ("PCI: intel-gw: Add .start_link() callback") Signed-off-by: Sasha Levin commit 28c35ea3515fc43fb1dcf9b05c20c73aa47ea32a Author: Florian Eckert Date: Fri Apr 17 10:35:47 2026 +0200 PCI: intel-gw: Move interrupt enable to own function [ Upstream commit abddc0539e5931f4ad2f589a03cbba5a6a64485f ] To improve the readability of the code, move the interrupt enable instructions to a separate function. That is already done for the disable interrupt instruction. In addition, clear and disable all pending interrupts, as is done in intel_pcie_core_irq_disable(). After that, enable all relevant interrupts again. The 'PCIE_APP_IRNEN' definition contains all the relevant interrupts that are of interest. This change is also done in the MaxLinear SDK [1]. As I unfortunately don’t have any documentation for this IP core, I suspect that the intention is to set the IP core for interrupt handling to a specific state. Perhaps the problem is that the IP core did not reinitialize the interrupt register properly after a power cycle. In my view, it can’t do any harm to switch the interrupt off and then on again to set them to a specific state. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-3-0a2b933fe04f@dev.tdt.de Stable-dep-of: 1eedabe7c617 ("PCI: intel-gw: Add .start_link() callback") Signed-off-by: Sasha Levin commit fc9d6f81587185844dd220ef23c9e05a7823abde Author: Ian Rogers Date: Tue May 5 17:45:43 2026 -0700 perf tool: Fix missing schedstat delegates and dont_split_sample_group in delegate_tool [ Upstream commit 09d355618f7ccc27ffc7fc668b2e232872962079 ] delegate_tool was missing the delegate overrides for schedstat_cpu and schedstat_domain. As a result, when allocated with zalloc, these callbacks defaulted to NULL, causing a segmentation fault crash if any schedstat events were delivered during event processing. Fix this by adding delegate_schedstat_cpu and delegate_schedstat_domain via the CREATE_DELEGATE_OP2 macro, and ensuring delegate_tool__init correctly registers them. Additionally, delegate_tool__init completely omitted copying the dont_split_sample_group property from the delegate. This would cause wrapper tools to default the flag to false, which corrupts piped event processing (e.g., in perf inject) by triggering duplicate event deliveries on split sample values in deliver_sample_group(). Similarly, perf_tool__init() omitted the initialization of this boolean field. On stack-allocated tools that rely on this initializer (like intel-tpebs or __cmd_evlist), this could result in uninitialized stack garbage evaluating to true—silently dropping non-leader event members in deliver_sample_group(). Fix both issues by properly copying the field in delegate_tool__init and initializing it to false in perf_tool__init. Fixes: 6331b266935916bf ("perf tool: Add a delegate_tool that just delegates actions to another tool") Fixes: 79bcd34e0f3da39f ("perf inject: Fix leader sampling inserting additional samples") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Gabriel Marin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6ed3cea56b778620b213caef0656416d0c5fb57a Author: Ian Rogers Date: Tue May 5 17:45:42 2026 -0700 perf sched: Add missing mmap2 handler in timehist [ Upstream commit 91182741369b261c441e63e6678893032a6d7e4c ] perf_sched__timehist() registers event handlers for options using the sched->tool struct. It registers handlers for MMAP, COMM, EXIT, FORK, etc. but completely omits registering a handler for MMAP2 events. Failing to register both MMAP and MMAP2 handlers causes modern systems (which primarily output MMAP2 records) to silently drop VMA map mappings. This results in uninitialized machine/thread mapping structures, making it impossible to resolve shared library instruction pointers (IPs) to dynamic symbols/DSOs during timehist callchain analysis. Fix this by correctly registering perf_event__process_mmap2 in sched->tool inside perf_sched__timehist(). Fixes: 49394a2a24c78ce0 ("perf sched timehist: Introduce timehist command") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: David Ahern Cc: Gabriel Marin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f05c3b4c9cc07b31745ead77d1285330d31d6f1d Author: Rafael J. Wysocki Date: Fri May 8 19:40:31 2026 +0200 platform/x86: xo15-ebook: Fix wakeup source and GPE handling [ Upstream commit b2fc2c6ebbd2d49935c8960755d8170faead2159 ] The device_set_wakeup_enable() call in ebook_switch_add() doesn't actually do anything because power.can_wakeup is not set for ACPI device objects. Moreover, had it done anything, it would have registered a wakeup source object that wouldn't have been used going forward and that wakeup source would have been leaked after driver removal because ebook_switch_remove() doesn't clean it up. Accordingly, remove that call from ebook_switch_add(). Also prevent leaking an enabled ACPI GPE after removing the driver by adding appropriate cleanup code to ebook_switch_remove(). Fixes: 89ca11771a4b ("OLPC XO-1.5 ebook switch driver") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1966125.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit df6d71c9a818eed13aa0f1f5d20d3ed201451269 Author: Rafael J. Wysocki Date: Fri May 8 20:00:27 2026 +0200 x86/platform/olpc: xo15: Drop wakeup source on driver removal [ Upstream commit cc966553e6ff0849978b5754531b768b0ff54985 ] Prevent leaking a wakeup source object after removing the driver by adding appropriate cleanup code to its remove callback function. Fixes: a0f30f592d2d ("x86, olpc: Add XO-1.5 SCI driver") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2069931.usQuhbGJ8B@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 721ad5b72448b5065ed309017ab563205f162404 Author: Guixin Liu Date: Fri May 8 16:21:28 2026 +0800 PCI: Check ROM header and data structure addr before accessing [ Upstream commit 538796b807fcfb81b2ce40cc97a614fd8588feb5 ] We meet a crash when running stress-ng on x86_64 machine: BUG: unable to handle page fault for address: ffa0000007f40000 RIP: 0010:pci_get_rom_size+0x52/0x220 Call Trace: pci_map_rom+0x80/0x130 pci_read_rom+0x4b/0xe0 kernfs_file_read_iter+0x96/0x180 vfs_read+0x1b1/0x300 Our analysis reveals that the ROM space's start address is 0xffa0000007f30000, and size is 0x10000. Because of broken ROM space, before calling readl(pds), the pds's value is 0xffa0000007f3ffff, which is already pointed to the ROM space end, invoking readl() would read 4 bytes therefore cause an out-of-bounds access and trigger a crash. Fix this by adding image header and data structure checking. We also found another crash on arm64 machine: Unable to handle kernel paging request at virtual address ffff8000dd1393ff Mem abort info: ESR = 0x0000000096000021 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault The call trace is the same with x86_64, but the crash reason is that the data structure addr is not aligned with 4, and arm64 machine report "alignment fault". Fix this by adding alignment checking. Fixes: 47b975d234ea ("PCI: Avoid iterating through memory outside the resource window") Suggested-by: Guanghui Feng Signed-off-by: Guixin Liu [bhelgaas: shorten function names, wrap comments] Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260508082128.3344255-3-kanie@linux.alibaba.com Signed-off-by: Sasha Levin commit 4e82818ead50b985ccd44e420fbfc313ddc02e5a Author: Guixin Liu Date: Fri May 8 16:21:27 2026 +0800 PCI: Introduce named defines for PCI ROM [ Upstream commit 113e86bc58a918f85d250723436a4d541a873358 ] Convert the magic numbers associated with PCI ROM into named definitions. Some of these definitions will be used in the second fix patch. Signed-off-by: Guixin Liu Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Reviewed-by: Krzysztof Wilczyński Link: https://patch.msgid.link/20260508082128.3344255-2-kanie@linux.alibaba.com Stable-dep-of: 538796b807fc ("PCI: Check ROM header and data structure addr before accessing") Signed-off-by: Sasha Levin commit d50ba5e4642c05b4d39ce5c6f5b1aa18fd224563 Author: Carlos Bilbao Date: Mon Apr 27 21:01:04 2026 -0700 PCI/ASPM: Don't reconfigure ASPM entering low-power state [ Upstream commit c855c9921da72e535c24737c748f603a52d03f7e ] Reconfiguring ASPM when a device transitions to low-power state can enable L1.1/L1.2 substates on the PCIe link at a time when the device is sleeping and may be unable to exit them. ASPM should be reconfigured on D0 entry (resume), not on the way down. pci_set_low_power_state() calls pcie_aspm_pm_state_change() after writing D3hot to PCI_PM_CTRL. pcie_aspm_pm_state_change() resets link->aspm_capable to link->aspm_support and then calls pcie_config_aspm_path(), which can enable ASPM L1.1/L1.2 substates on the PCIe link. If the device cannot recover the link from L1.2 while in D3hot, subsequent config space reads return 0xFFFF ("device inaccessible") and pci_power_up() fails with messages like: vfio-pci 0000:5d:00.0: Unable to change power state from D3hot to D0, device inaccessible This was observed on NVIDIA H100 SXM5 GPUs bound to vfio-pci when Linux runtime PM suspends them to D3hot: the GPU becomes permanently inaccessible and disappears from the PCIe bus. The call to pcie_aspm_pm_state_change() in pci_set_low_power_state() was restored by f93e71aea6c6 ("Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()""), which reverted 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()"). The revert was necessary because the removal broke suspend/resume on certain platforms that required ASPM to be reconfigured on D0 entry. However, the revert restored the call in both pci_set_full_power_state() (D0 entry) and pci_set_low_power_state() (low-power entry). Only the D0-entry call is needed to fix the suspend/resume regression. The low-power-entry call is harmful: reconfiguring ASPM immediately after putting a device into D3hot can enable link substates that the device or platform cannot exit while the device is sleeping. Remove the pcie_aspm_pm_state_change() call from pci_set_low_power_state(). ASPM will still be reconfigured correctly when the device returns to D0 via pci_set_full_power_state(). Fixes: f93e71aea6c6 ("Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()"") Signed-off-by: Carlos Bilbao (Lambda) Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260428040104.78524-1-carlos.bilbao@kernel.org Signed-off-by: Sasha Levin commit 12007c55d9c08f837e5f29daba32e04ee7ca22c3 Author: Leo Yan Date: Wed Apr 8 13:31:43 2026 +0100 coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore [ Upstream commit 0ec0a8785d21f63db520bd9d2a67c55e855d36a8 ] It is a typo to use trcvmidcctlr0 to save and restore TRCVMIDCCTLR1. Use trcvmidcctlr1 instead. Fixes: f5bd523690d2 ("coresight: etm4x: Convert all register accesses") Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260408-arm_cs_fix_trcvmidcctlr1_typo-v1-1-6a5695363b46@arm.com Signed-off-by: Sasha Levin commit 293dacd5b6a9f1275d92ca6c4fd874e54b2c8319 Author: James Clark Date: Tue May 5 17:51:25 2026 +0100 coresight: ete: Always save state on power down [ Upstream commit 2ab4645fe4206c142a5f1491e191c906279686cf ] System register ETMs and ETE are unlikely to be preserved on CPU power down. The ETE DT binding also never documented "arm,coresight-loses-context-with-cpu" so nobody would have legitimately been able to use that binding to fix it and ACPI has no such binding at all. Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg) or ACPI boots. Use a local variable when setting up save_state so that it's immune to concurrent probing when devices have different configurations which is an issue with modifying the global. This fixes the following error when using Coresight with ACPI on the FVP which supports CPU PM: coresight ete0: External agent took claim tag WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117 Fixes: 35e1c9163e02 ("coresight: ete: Add support for ETE tracing") Signed-off-by: James Clark Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260505-james-cs-ete-pm_save_enable-v3-1-485d21dd79b8@linaro.org Signed-off-by: Sasha Levin commit 9d802907fc2a57adf2cb83d7ec55e4e337922857 Author: Leo Yan Date: Tue Feb 17 13:19:43 2026 +0000 coresight: tmc: Fix overflow when calculating is bigger than 2GiB [ Upstream commit f195d54deef1bc6dd3326394975baff02c7ae487 ] When specifying a 2GB AUX buffer, the ETR driver ends up allocating only a 1MB buffer instead: # echo 'file coresight-tmc-etr.c +p' > \ /sys/kernel/debug/dynamic_debug/control # perf record -e cs_etm/@tmc_etr0,timestamp=0/u -C 0 -m ,2G -- test coresight tmc_etr0: allocated buffer of size 1024KB in mode 0 The page index is an 'int' type, and shifting it by PAGE_SHIFT overflows when the resulting value exceeds 2GB. This produces a negative value, causing the driver to fall back to the minimum buffer size (1MB). Cast the page index to a wider type to accommodate large buffer sizes. Also fix a similar issue in the buffer offset calculation. Reported-by: Michiel van Tol Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Fixes: eebe8dbd8630 ("coresight: tmc: Decouple the perf buffer allocation from sysfs mode") Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260217-arm_coresight_fix_big_buffer_size-v1-1-774e893d8e3f@arm.com Signed-off-by: Sasha Levin commit e483a406a23a92d5202e8d324f206e127eef48ff Author: Baoli.Zhang Date: Wed May 6 13:50:35 2026 +0800 soundwire: fix bug in sdw_add_element_group_count found by syzkaller [ Upstream commit f772ff5a0e6758fd412803c09e03ba3bca5f5878 ] The original implementation caused an out-of-bounds memory access in the sdw_add_element_group_count for-loop when i == num. for (i = 0; i <= num; i++) { if (rate == group->rates[i] && lane == group->lanes[i]) ... To fix this error, the function now checks for existing rate/lane entries in the group(a function parameter) using a for-loop before adding them. No functional changes apart from this fix. Fixes: 9026118f20e2 ("soundwire: Add generic bandwidth allocation algorithm") Reviewed-by: Bard Liao Reviewed-by: Andy Shevchenko Signed-off-by: Baoli.Zhang Link: https://patch.msgid.link/20260506055039.3751028-2-baoli.zhang@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f0481e6bcc5d34cae85b244b1479784ee79df877 Author: Bard Liao Date: Tue Apr 28 16:46:12 2026 +0800 soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached Peripheral [ Upstream commit c368dd5cbd61ffab2b6f8a89b0d5775e2e16cde6 ] The SDW_SCP_BUSCLOCK_SCALE register will be programmed when the Peripheral is attached. We can and should skip programming the SDW_SCP_BUSCLOCK_SCALE register when the Peripheral is unattached. Fixes: 645291cfe5e5 ("Soundwire: stream: program BUSCLOCK_SCALE") Signed-off-by: Bard Liao Reviewed-by: Simon Trimmer Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260428084612.322701-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fbd5d3168740f57d029fab74aa7dbe6e82b72358 Author: Yingchao Deng Date: Sun Apr 26 17:59:34 2026 +0800 coresight: cti: Fix DT filter signals silently ignored [ Upstream commit 551bb2fd5e4ed63d33aa11f07102cce5179b7595 ] In cti_plat_process_filter_sigs(), after allocating a temporary cti_trig_grp struct via kzalloc_obj(), the code never assigns tg->nr_sigs = nr_filter_sigs. Since kzalloc zero-initialises the struct, tg->nr_sigs remains 0. cti_plat_read_trig_group() guards with: if (!tgrp->nr_sigs) return 0; so it returns immediately without reading any signal indices from DT. Fix by assigning tg->nr_sigs before calling cti_plat_read_trig_group(). Fixes: a5614770ab97 ("coresight: cti: Add device tree support for custom CTI") Signed-off-by: Yingchao Deng Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260426-nr_sigs-v1-1-3b9df99dab97@oss.qualcomm.com Signed-off-by: Sasha Levin commit 2830eedfcc7dc4c387a47046478d8e561d7f89a0 Author: Thomas Richter Date: Tue Apr 14 14:42:41 2026 +0200 perf callchain: Handle multiple address spaces [ Upstream commit ae15db3e9b639491007cc1e9e99638e4b6091781 ] perf test 'perf inject to convert DWARF callchains to regular ones' fails on s390. It was introduced with commit 92ea788d2af4e65a ("perf inject: Add --convert-callchain option") The failure comes the difference in output. Without the inject script to convert DWARF the callchains is: # perf record -F 999 --call-graph dwarf -- perf test -w noploop # perf report -i perf.data --stdio --no-children -q \ --percent-limit=1 > /tmp/111 # cat /tmp/111 99.30% perf-noploop perf [.] noploop | ---noploop run_workload (inlined) cmd_test run_builtin (inlined) handle_internal_command run_argv (inlined) main __libc_start_call_main __libc_start_main_impl (inlined) _start # With the inject script step the output is: # perf inject -i perf.data --convert-callchain -o /tmp/perf-inject-1.out # perf report -i /tmp/perf-inject-1.out --stdio --no-children -q \ --percent-limit=1 > /tmp/222 # cat /tmp/222 99.40% perf-noploop perf [.] noploop | ---noploop run_workload (inlined) cmd_test run_builtin (inlined) handle_internal_command run_argv (inlined) main _start # diff /tmp/111 /tmp/222 1c1 < 99.30% perf-noploop perf [.] noploop --- > 99.40% perf-noploop perf [.] noploop 10,11d9 < __libc_start_call_main < __libc_start_main_impl (inlined) # The difference are the symbols __libc_start_call_main and __libc_start_main_impl. On x86_64, kernel and user space share a single virtual address space, with the kernel mapped to the upper end of memory. The instruction pointer value alone is sufficient to distinguish between user space and kernel space addresses. This is not true for s390, which uses separate address spaces for user and kernel. The same virtual address can be valid in both address spaces, so the instruction pointer value alone cannot determine whether an address belongs to the kernel or user space. Instead, perf must rely on the cpumode metadata derived from the processor status word (PSW) at sample time. In function perf_event__convert_sample_callchain() the first part copies a kernel callchain and context entries, if any. It then appends additional entries ignoring the address space architecture. Taking that into account, the symbols at addresses 0x3ff970348cb __libc_start_call_main 0x3ff970349c5 __libc_start_main_impl (located after the kernel address space on s390) are now included. Output before: # perf test 83 83: perf inject to convert DWARF callchains to regular ones : FAILED! Output after: # perf test 83 83: perf inject to convert DWARF callchains to regular ones : Ok Question to Namhyung: In function perf_event__convert_sample_callchain() just before the for() loop this patch modifies, the kernel callchain is copied, see this comment and the next 5 lines: /* copy kernel callchain and context entries */ Then why is machine__kernel_ip() needed in the for() loop, when the kernel entries have been copied just before the loop? Note: This patch was tested on x86_64 virtual machine and succeeded. Fixes: 92ea788d2af4e65a ("perf inject: Add --convert-callchain option") Signed-off-by: Thomas Richter Acked-by: Namhyung Kim Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Jan Polensky Cc: linux-s390@vger.kernel.org Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ffddd64eae0b39b8074bbcee24b0fc10cef42b2e Author: Ian Rogers Date: Mon May 4 01:12:27 2026 -0700 perf debuginfo: Fix libdw API contract violations [ Upstream commit 31088ccf0312b1a547046f1f69890ede07834a30 ] Check return value of `dwfl_report_end` during offline initialization. Validate `dwfl_module_relocation_info` result before passing to `strcmp` to avoid potential segmentation faults. Additionally: - Fix a file descriptor leak in `debuginfo__init_offline_dwarf()` when `dwfl_report_offline()` or subsequent setup calls fail. Fixes: 6f1b6291cf73cb32 ("perf tools: Add util/debuginfo.[ch] files") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2a86103b44af9ad8e7b673ded90dd55fb04d0a66 Author: Ian Rogers Date: Mon May 4 01:12:26 2026 -0700 perf annotate-data: Fix libdw API contract violations [ Upstream commit 5aa1941900050a2c80d29bc7ee0dfbddbad8f294 ] Check return values of `dwarf_aggregate_size` and `dwarf_formudata`. Additionally: - Avoid `vfprintf` undefined behavior with `NULL` strings by using the `die_name()` helper for `dwarf_diename()` in `pr_*` calls. - Use `die_get_data_member_location()` (updated to use `dwarf_attr_integrate`) to correctly parse location expressions for inherited member locations in the fallback path when `dwarf_formudata()` fails. Fixes: 2bc3cf575a162a2c ("perf annotate-data: Improve debug message with location info") Fixes: 4a111cadac85362e ("perf annotate-data: Add member field in the data type") Fixes: 8b1042c425f6a5a9 ("perf annotate-data: Set bitfield member offset and size properly") Fixes: fc044c53b99fad03 ("perf annotate-data: Add dso->data_types tree") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 881af00c02c07117fe243580a4e9b393ebd989e0 Author: Ian Rogers Date: Mon May 4 01:12:25 2026 -0700 perf probe-finder: Fix libdw API contract violations [ Upstream commit 9a2ef19b5f5218d35c161f272a901f6c070faf79 ] Check return values of `dwarf_formsdata`, `dwarf_entrypc`, `dwarf_highpc`, `dwarf_bytesize`, `dwarf_attr`, `dwarf_decl_line`, `dwarf_getfuncs`, and `dwarf_formref_die`. Validate `dwarf_diename` and `dwarf_diecu` results to prevent potential crashes. Fix C90 mixed declarations. Additionally: - Avoid vfprintf undefined behavior with NULL strings by using the `die_name()` helper for `dwarf_diename()` in `pr_*` calls, including when warning about tail calls. - Prevent NULL pointer dereference in `convert_variable_fields()` when processing array elements for variables in registers. - Fallback to offset 0 in `line_range_search_cb()` instead of skipping functions without `DW_AT_decl_line`. - Relax `dwarf_getfuncs` error checking in `find_probe_point_by_func()` and `find_line_range_by_func()` to prevent premature CU search aborts, ensuring robustness against corrupted CUs. Fixes: 66f69b2197167cb9 ("perf probe: Support DW_AT_const_value constant value") Fixes: 3d918a12a1b3088a ("perf probe: Find fentry mcount fuzzed parameter location") Fixes: bcfc082150c6b1e9 ("perf probe: Remove redundant dwarf functions") Fixes: 221d061182b8ff55 ("perf probe: Fix to search local variables in appropriate scope") Fixes: b55a87ade3839c33 ("perf probe: Remove die() from probe-finder code") Fixes: 4c859351226c920b ("perf probe: Support glob wildcards for function name") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d739d9f4525b8cd475b8f84b0ac901d8bc24925e Author: Ian Rogers Date: Mon May 4 01:12:24 2026 -0700 perf libdw: Fix libdw API contract violations and memory leaks [ Upstream commit 9c6d535ddb794fb540c3b142ab1d7416d469c1de ] Check return values of `dwfl_report_end` and `dwfl_module_addrdie` to prevent using uninitialized stack variables or reporting success on failure. Additionally: - Ensure `*file` is freed and inline frames are cleared on error in `libdw__addr2line()` to prevent memory leaks and duplicated callchains when falling back to other unwinders. - Use `die_name()` safe wrapper inside the inline function unwinding callback (`libdw_a2l_cb`). - Refactor `libdw_a2l_cb`'s repeated memory error handling/cleanup paths using a cleaner goto control flow. Fixes: b7a2b011e9627ff3 ("perf powerpc: Unify the skip-callchain-idx libdw with that for addr2line") Fixes: 88c51002d06f9a68 ("perf addr2line: Add a libdw implementation") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e542c8800bbc714d0e7bcca0d414ff2b3a745a06 Author: Ian Rogers Date: Mon May 4 01:12:21 2026 -0700 perf srcline: Introduce inline_node__clear_frames() commit 674dea094ef6594ea1aa0efb074a4646a81350b2 upstream. Introduce inline_node__clear_frames() to clean up partial allocations. This is a prerequisite for error handling in libdw inline unwinding. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit eb0062b3e76d8ef6d78eabcdda771424fc9276b4 Author: Ian Rogers Date: Mon May 4 01:12:20 2026 -0700 perf dwarf-aux: Fix libdw API contract violations [ Upstream commit 17e9b4243e76f0a0fe951d30ce990d6081a8b426 ] Check return values of `dwarf_decl_line` (where non-optional), `dwarf_getfuncs`, and `dwarf_lineaddr` to prevent using uninitialized stack variables or incorrectly reporting success on failure. For the root DIE in `die_walk_lines()`, `dwarf_decl_line` and `die_get_decl_file` are optional and their failures are handled gracefully to avoid breaking line walking on valid functions. Specifically, remove the strict `!decf` (declared file) check that would prematurely abort line walking on generated or artificial functions lacking this optional attribute. Additionally: - Add NULL pointer protection for `strcmp()` in `die_walk_lines()` when `inf` or `decf` are NULL to prevent crashes on generated code. - Use `dwarf_attr_integrate` in `die_get_data_member_location` to correctly resolve inherited member locations (e.g. via abstract origin or specification). Fixes: 57f95bf5f882 ("perf probe: Show correct statement line number by perf probe -l") Fixes: 3f4460a28fb2 ("perf probe: Filter out redundant inline-instances") Fixes: 75186a9b09e4 ("perf probe: Fix to show lines of sys_ functions correctly") Fixes: e0d153c69040 ("perf-probe: Move dwarf library routines to dwarf-aux.{c, h}") Fixes: 6243b9dc4c99 ("perf probe: Move dwarf specific functions to dwarf-aux.c") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 23ec342a8fa649c543fe8cc8a62eff88fe74df3b Author: Ian Rogers Date: Mon May 4 01:12:19 2026 -0700 perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at [ Upstream commit d37a5467709e627370124d7346ef71ce605ababa ] A segmentation fault was observed in `libdw` when running `perf kmem` with `--page stat` on some workloads. The crash occurred deep inside `libdw` (specifically in `dwarf_child` and `dwarf_diename`) when processing DWARF information. The root cause was improper error handling of `dwarf_getfuncs` in `die_find_realfunc` and `die_find_tailfunc`. `dwarf_getfuncs` returns: - `0` on success (when all functions have been processed). - A positive offset if the callback aborts early (e.g., via `DWARF_CB_ABORT` when a match is found). - `-1` on error. The original code used `if (!dwarf_getfuncs(...)) return NULL;`. On error (`-1`), `!-1` evaluates to `0` (false), bypassing the error check. Execution then proceeded as if a match was found, returning uninitialized stack memory (`die_mem`) to the caller (`cu_walk_functions_at`). When `cu_walk_functions_at` passed this uninitialized memory to `libdw` via `dwarf_diename`, it caused a segmentation fault. Fix this by correcting the error check to `if (dwarf_getfuncs(...) <= 0)`. Fixes: e0d153c69040 ("perf-probe: Move dwarf library routines to dwarf-aux.{c, h}") Fixes: d4c537e6bf86 ("perf probe: Ignore tail calls to probed functions") Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Peter Zijlstra Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5de04caa46b635e180cecbd164e333eca535db94 Author: Alexandru Hossu Date: Mon Apr 27 10:17:12 2026 +0200 staging: nvec: fix use-after-free in nvec_rx_completed() [ Upstream commit 26813881181deb3a32fbb59eadb2599cbe8423f6 ] In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check. Fixes: d6bdcf2e1019 ("staging: nvec: Add battery quirk to ignore incomplete responses") Reviewed-by: Dan Carpenter Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260427081713.3401874-2-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fde2296f87b72ccd72460ce13ad56e8652b321d4 Author: Maksym Pikhotskyi Date: Fri Apr 17 13:54:51 2026 +0400 staging: rtl8723bs: fix stainfo check in rtw_aes_decrypt [ Upstream commit 9a3f9b3c47d8f071b0eb9e63906ac0448058278d ] The null-pointer-guard was incorrect, returning _FAIL on valid pointer. Invert the guard, so it returns _FAIL on invalid pointer. Fixes: e23ad1570028 ("staging: rtl8723bs: use guard clause for stainfo check") Reported-by: Luka Gejak Closes: https://lore.kernel.org/linux-staging/E4BF62EF-C6F6-431F-8EDC-77C1E613E66B@linux.dev/ Reviewed-by: Dan Carpenter Signed-off-by: Maksym Pikhotskyi Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260417095452.23440-1-mpikhotskyi@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 697af8745d5c61e05eafa055dd0444d5bc45e6e6 Author: Stanley Chu Date: Mon Apr 13 08:50:39 2026 +0800 i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845 [ Upstream commit fa1d4fa118f4229168e9ca88cea260c5e5a94652 ] The NPCM845 I3C controller may raise a false SLVSTART interrupt. The handler first latches MSTATUS and then clears SLVSTART. If a real IBI request arrives after the handler latches MSTATUS but before it clears the SLVSTART interrupt status, HW sets the SLVREQ state. However, the handler still relies on the stale MSTATUS snapshot, returns early, and misses the real IBI. No further interrupt is generated for this pending IBI. Re-read MSTATUS to obtain the latest state and avoid missing a real IBI due to this race condition. Fixes: 4dd12e944f07 ("i3c: master: svc: Fix npcm845 invalid slvstart event") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260413005040.1211107-2-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b0194db10032e08e82fc6a0a359bde4a8bda68ab Author: Mario Limonciello Date: Tue Apr 28 21:52:39 2026 -0500 gpiolib: acpi: Only trigger ActiveBoth interrupts on boot [ Upstream commit 3bb62e3f99a557d257e5f5a803200051b7de3afa ] Commit ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") introduced logic to trigger edge-based GPIO interrupts during initialization to ensure proper initial state setup when firmware doesn't initialize it. However, according to the Microsoft GPIO documentation, triggering GPIO interrupts during initialization should only happen for interrupts marked as ActiveBoth (both IRQF_TRIGGER_RISING and IRQF_TRIGGER_FALLING) and only when the associated GPIO line is already asserted (logic level low). The current implementation incorrectly triggers: 1. Any edge-triggered interrupt (RISING-only or FALLING-only) 2. RISING interrupts when value is high and FALLING when value is low This causes problems at bootup for single-edge interrupts that don't follow the ActiveBoth pattern. Fix this by: - Only triggering when BOTH rising and falling edges are configured - Only triggering when the GPIO line is asserted (value == 0) Reported-by: Francesco Lauritano Closes: https://lore.kernel.org/all/6iFCwGH2vssb7NRUTWGpkubGMNbgIlBHSz40z8ZsezjxngXpoiiRiJaijviNvhiDAGIr43bfUmdxLmxYoHDjyft4DgwFc3Pnu5hzPguTa0s=@protonmail.com/ Tested-by: Marco Scardovi Fixes: ca876c7483b69 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/general-purpose-i-o--gpio- Suggested-by: Armin Wolf Signed-off-by: Mario Limonciello Reviewed-by: Mika Westerberg Reviewed-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 4791b91daeb1959865bf73be3bf141f58dbccd67 Author: Nam Cao Date: Tue Jun 2 19:51:46 2026 +0200 eventpoll: Fix epoll_wait() report false negative [ Upstream commit 0c4aefe3c2d0f272a2ad73699a12d4446ffdbe7b ] ep_events_available() checks for available events by looking at ep->rdllist and ep_is_scanning(). However, this is done without a lock and can report false negative if ep_start_scan() or ep_done_scan() are executed by another task concurrently. For example: _________________________________________________________________________ |ep_start_scan() | list_splice_init(&ep->rdllist, ...) ep_events_available() | !list_empty_careful(&ep->rdllist)| || ep_is_scanning(ep) | | ep_enter_scan(ep) ___________________________________|_____________________________________ Another example: _________________________________________________________________________ ep_events_available() | |ep_start_scan() | list_splice_init(&ep->rdllist, ...) | ep_enter_scan(ep) !list_empty_careful(&ep->rdllist)| |ep_done_scan() | ep_exit_scan(ep) | list_splice(..., &ep->rdllist) || ep_is_scanning(ep) | ___________________________________|_____________________________________ In the above examples, ep_events_available() sees no event despite events being available. In case epoll_wait() is called with timeout=0, epoll_wait() will wrongly return "no event" to user. Introduce a sequence lock to resolve this issue. Measuring the time consumption of 10 million loop iterations doing epoll_wait(), the following performance drop is observed: timeout #event before after diff 0ms 0 3727ms 3974ms +6.6% 0ms 1 8099ms 9134ms +13% 1ms 1 13525ms 13586ms +0.45% Considering the use case of epoll_wait() (wait for events, do something with the events, repeat), it should only contribute to a small portion of user's CPU consumption. Therefore this performance drop is not alarming. Fixes: c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") Suggested-by: Mateusz Guzik Signed-off-by: Nam Cao Link: https://patch.msgid.link/4363cd8e34a21d4f0d257be1b33e84dc25030fdf.1780422138.git.namcao@linutronix.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 8679e9e068762d1964330dc4bc7717ddcac6da31 Author: Christian Brauner Date: Fri Apr 24 15:46:46 2026 +0200 eventpoll: rename epi->next and txlist for clarity [ Upstream commit f38567bb63ae029e3b63fcb99b6a2dcc6f421e69 ] Two list-related names were confusing in isolation: struct epitem::next A singly-linked link slot used only when an epi is queued on ep->ovflist during an ep_start_scan/ep_done_scan window. The bare name "next" suggests a generic list link and doesn't say which list it belongs to. txlist The caller-local list_head used by ep_send_events() and __ep_eventpoll_poll() to hold the batch of items stolen from ep->rdllist for the current scan. "txlist" ("transmission list") is abbreviated and overloaded: it doesn't distinguish itself from ep->rdllist or ep->ovflist at a glance. Rename for what each actually is: struct epitem::next -> struct epitem::ovflist_next local txlist -> scan_batch With these in place: - epi->ovflist_next reads as "this is the ep->ovflist link slot", matching the rdllink pattern above it. - scan_batch reads as "the batch currently being scanned", clearly distinct from rdllist (canonical ready list) and ovflist (scan-window overflow). ep->rdllist and ep->ovflist struct field names are preserved -- they are long-standing interface-facing identifiers, and the new inline helpers (ep_is_scanning, epi_on_ovflist, ...) already hide the sentinel semantics at call sites. No functional change. Signed-off-by: Christian Brauner (Amutable) Link: https://patch.msgid.link/20260424-work-epoll-rework-v1-15-249ed00a20f3@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit b698ee9abf409e0ddd4c9f5eceb56fd27cc956d8 Author: Christian Brauner Date: Fri Apr 24 15:46:32 2026 +0200 eventpoll: expand top-of-file overview / locking doc [ Upstream commit 7c25a0bd4bf7139944c5893ff61211f4b5a3455e ] The existing ~40-line "LOCKING:" banner covered the three-level lock hierarchy (epnested_mutex > ep->mtx > ep->lock) but nothing else. Lifetime rules, the ready-list state machine, the three removal paths, and the POLLFREE contract are implicit in the code. The recent UAF series (a6dc643c6931, 07712db80857, 8c2e52ebbe88, f2e467a48287) rode on invariants that were only implicit. Codify them at the top of the file: the subsystem overview, the lock hierarchy and its mutex_lock_nested() subclass convention (reworded from the old banner), a field-protection table for struct eventpoll and struct epitem that names the two faces of the rbn/rcu union (rbn under ep->mtx while linked into ep->rbr; rcu touched only by kfree_rcu(epi) on the free path), the ovflist sentinel encoding and scan-flip invariants, the three removal paths (A ep_remove, B ep_clear_and_put, C eventpoll_release_file) and the epi_fget() pin that orchestrates A vs C, and the POLLFREE store-release / load-acquire handshake. No functional change. Signed-off-by: Christian Brauner (Amutable) Link: https://patch.msgid.link/20260424-work-epoll-rework-v1-1-249ed00a20f3@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit 0c44866f4a23b9c2ceebedaf1b3a842857095e07 Author: Gui-Dong Han Date: Fri May 29 15:54:41 2026 +0800 9p: Add missing read barrier in virtio zero-copy path [ Upstream commit aa88278693cbfaf7a2acf961379973fbb63b165c ] Commit 2b6e72ed747f ("9P: Add memory barriers to protect request fields over cb/rpc threads handoff") added a read barrier after p9_client_rpc() waits for req->status, pairing with the write barrier in p9_client_cb(). The virtio zero-copy wait path was missed. Add the same read barrier after the zero-copy wait before reading the completed request. Fixes: 2b6e72ed747f ("9P: Add memory barriers to protect request fields over cb/rpc threads handoff") Signed-off-by: Gui-Dong Han Message-ID: <20260529075441.233369-1-hanguidong02@gmail.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit ebbcbe5c0db215feecc17def06178da443f4eea6 Author: Yizhou Zhao Date: Fri May 29 15:39:31 2026 +0800 net/9p: fix race condition on rdma->state in trans_rdma.c [ Upstream commit 7d54894a1ee265a72d70f7cae1da6cc774cccc71 ] The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions. Fixes: 473c7dd1d7b5 ("9p/rdma: remove useless check in cm_event_handler") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao Message-ID: <20260529073933.77315-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit fdc9043cfd50262e86dcb4d5d4ac233ddeb6ff3b Author: Hongling Zeng Date: Wed May 20 10:26:50 2026 +0800 9p: avoid returning ERR_PTR(0) from mkdir operations [ Upstream commit 314b58c01a9047567fd19446ca5fd46c473b89ff ] When mkdir succeeds, v9fs_vfs_mkdir_dotl() and v9fs_vfs_mkdir() return ERR_PTR(0) which is incorrect. They should return NULL instead for success and ERR_PTR() only with negative error codes for failure. Return NULL instead of passing to ERR_PTR while err is zero Fixes smatch warnings: fs/9p/vfs_inode_dotl.c:420 v9fs_vfs_mkdir_dotl() warn: passing zero to 'ERR_PTR' fs/9p/vfs_inode.c:695 v9fs_vfs_mkdir() warn: passing zero to 'ERR_PTR' The v9fs_vfs_mkdir() code was further simplified because v9fs_create() can never return NULL, so we do not need to check for fid being set separately, and the error path can be a simple return immediately after v9fs_create() failure. There is no intended functional change. Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Suggested-by: David Laight Acked-by: Christian Schoenebeck Signed-off-by: Hongling Zeng Message-ID: <20260520022650.14217-1-zenghongling@kylinos.cn> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit f3dd1e534e9de64669415f8239e0094afecfed78 Author: Aleksandr Nogikh Date: Fri Jun 12 11:50:20 2026 +0000 ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write [ Upstream commit ff6f26c58421614b02694ac9d219ac61d924bc68 ] A circular locking dependency involves INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE, and ORPHAN_DIR_SYSTEM_INODE. 1. ocfs2_mknod() acquires INODE_ALLOC then EXTENT_ALLOC. 2. ocfs2_dio_end_io_write() acquires EXTENT_ALLOC for unwritten extents, then ORPHAN_DIR via ocfs2_del_inode_from_orphan() while still holding EXTENT_ALLOC. 3. ocfs2_wipe_inode() acquires ORPHAN_DIR then INODE_ALLOC via ocfs2_remove_inode. Break the cycle in ocfs2_dio_end_io_write() by freeing the allocation contexts (releasing EXTENT_ALLOC) before acquiring ORPHAN_DIR. WARNING: possible circular locking dependency detected ------------------------------------------------------ is trying to acquire lock: ffff8881e78b33a0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}, at: ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299 but task is already holding lock: ffff8881e78b4fa0 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}, at: ocfs2_evict_inode+0xe97/0x43b0 fs/ocfs2/inode.c:1299 the existing dependency chain (in reverse order) is: -> #2 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}: inode_lock include/linux/fs.h:1029 [inline] ocfs2_del_inode_from_orphan+0x12e/0x7a0 fs/ocfs2/namei.c:2728 ocfs2_dio_end_io+0xf9c/0x1370 fs/ocfs2/aops.c:2418 dio_complete+0x25b/0x790 fs/direct-io.c:281 -> #1 (&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}: inode_lock include/linux/fs.h:1029 [inline] ocfs2_reserve_suballoc_bits+0x16d/0x4840 fs/ocfs2/suballoc.c:882 ocfs2_reserve_new_metadata_blocks+0x415/0x9a0 fs/ocfs2/suballoc.c:1078 ocfs2_mknod+0x10f3/0x2260 fs/ocfs2/namei.c:351 -> #0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}: __lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237 lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868 down_write+0x96/0x200 kernel/locking/rwsem.c:1625 inode_lock include/linux/fs.h:1029 [inline] ocfs2_remove_inode fs/ocfs2/inode.c:733 [inline] ocfs2_wipe_inode fs/ocfs2/inode.c:896 [inline] ocfs2_delete_inode fs/ocfs2/inode.c:1157 [inline] ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299 Chain exists of: &ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]); lock(&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]); lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]); lock(&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]); *** DEADLOCK *** Link: https://lore.kernel.org/97c902a6-3bcf-43ea-9b70-f1f136a6c3f2@mail.kernel.org Fixes: d647c5b2fbf8 ("ocfs2: split transactions in dio completion to avoid credit exhaustion") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+b225d4dfce6219600c42@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b225d4dfce6219600c42 Link: https://syzkaller.appspot.com/ai_job?id=0b53ce1e-2972-4192-aa85-8097a702762c Signed-off-by: Aleksandr Nogikh Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 17d79248b4f370663f9d351409a130fc1ed9416d Author: Charles Keepax Date: Fri May 8 14:48:04 2026 +0100 mfd: cs42l43: Sanity check firmware size [ Upstream commit b6ef1a74b3ec254f87a6a3c554fe8f8083ebd37c ] Currently the code checks if a firmware was received, however it does not verify that the firmware size is larger than the firmware header. As the firmware pointer is dereferenced as a pointer to the header structure this could lead to an out of bounds memory access. Add the missing check. Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260508134804.1787461-1-ckeepax@opensource.cirrus.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit afb1a5af6dd949196a4cf289751f3cca09d27469 Author: Matthew Bystrin Date: Wed Apr 29 10:20:46 2026 +0300 mfd: rsmu: Fix page register setup [ Upstream commit 6bc38f26ed07197b11a2b588edf1f43bfbc81d76 ] Fix writes to page register in 8A3400x family (Clock Matrix). All calls to rsmu_write_page_register() (both in i2c and spi) have resulted in early return, because all addresses in include/linux/mfd/idt8a340_reg.h are less than RSMU_CM_SCSR_BASE. There were 2 separate patch series which have to be merged in one time: mfd and ptp. The latter have been merged, the former[1] have not. Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/ Fixes: 67d6c76fc815 ("mfd: rsmu: Support 32-bit address space") Signed-off-by: Matthew Bystrin Link: https://patch.msgid.link/20260429072047.1111427-2-dev.mbstr@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e18ffb7541de052d21039a3e6ae0d719c5107369 Author: Matti Vaittinen Date: Tue Apr 7 16:26:48 2026 +0300 mfd: bd72720: Drop BUCK11 ID [ Upstream commit 6a2cb13761d90ef3fa960db189a2cc1bdf965ae1 ] The BD72720 header reserves an ID for BUCK11. While this does not (at the moment) cause problems I can see, it is misleading as the BD72720 contains only 10 BUCKs. Make the code clearer and drop the BUCK11 ID. Fixes: af25277b1ddc ("mfd: rohm-bd71828: Support ROHM BD72720") Signed-off-by: Matti Vaittinen Link: https://patch.msgid.link/812c3749a18d609d6f4698506bc516ec7183dfdd.1775565298.git.mazziesaccount@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0ff82a9cf9312678d8bc4edeef0b6e82659ac12a Author: Guangshuo Li Date: Fri Jun 5 12:30:16 2026 +0800 ksmbd: fix use-after-free in same_client_has_lease() [ Upstream commit 65b655f65c3ca1ab5d598d3832bb0ff531725858 ] same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Guangshuo Li Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2fface6e0bbd6314d1d9d071abf2c4d67548511c Author: Eric Dumazet Date: Tue Jun 16 14:13:17 2026 +0000 net: serialize netif_running() check in enqueue_to_backlog() [ Upstream commit 46762cefe7f4e5bffc1eb467810a7bbb02e461d7 ] Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped). Fixes: e9e4dd3267d0 ("net: do not process device backlog during unregistration") Reported-by: syzbot+965506b59a2de0b6905c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a315824.b0403584.28d0ff.0000.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Julian Anastasov Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260616141317.407791-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bde37aed0724c0139dea177f3aae8d989b6babb1 Author: Jacob Moroni Date: Tue Jun 16 15:56:01 2026 +0000 RDMA/irdma: Replace waitqueue and flag with completion [ Upstream commit d9c8c45e6d2f438a3c8e643ae78b59454fa0fadd ] The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Fixes: 915cc7ac0f8e ("RDMA/irdma: Add miscellaneous utility definitions") Link: https://patch.msgid.link/r/20260616155601.1081448-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bc4caea7a82bbcf94a34eff7094e7f9b501680ab Author: Junxian Huang Date: Sat Jun 13 18:20:45 2026 +0800 RDMA/hns: Fix memory leak of bonding resources [ Upstream commit c0bd03b850d81a8914168d87ddf7f6ffa58875ef ] In a corner case of concurrent driver removal and driver reset, bonding resource is first released in hns_roce_hw_v2_exit() during driver removal, and then is allocated again in hns_roce_register_device() during driver reset. This leads to memory leak because the release timing has already passed. This may also lead to a kernel panic as below because of the leaked notifier callback: Call trace: 0xffffa20fccc04978 (P) raw_notifier_call_chain+0x20/0x38 call_netdevice_notifiers_info+0x60/0xb8 netdev_lower_state_changed+0x4c/0xb8 As Sashiko suggested, the teardown order of bonding resources should be inverted to make sure the resources are released when the driver is removed. Fixes: b37ad2e290fc ("RDMA/hns: Initialize bonding resources") Link: https://patch.msgid.link/r/20260613102045.811623-1-huangjunxian6@hisilicon.com Signed-off-by: Junxian Huang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 967099102562d562c2a02cf5d00b722d3352da4d Author: Selvin Xavier Date: Mon Jun 15 15:47:51 2026 -0700 RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated [ Upstream commit 33a215f499b0643cd88a32ab5b8de1547be419c6 ] If a user calls BNXT_RE_METHOD_GET_TOGGLE_MEM on a device that does not support the CQ/SRQ toggle feature, uctx_cq_page or uctx_srq_page will be NULL. Add an explicit -EOPNOTSUPP return after capturing the address from uctx_cq_page / uctx_srq_page if the address is zero. Fixes: e275919d9669 ("RDMA/bnxt_re: Share a page to expose per CQ info with userspace") Fixes: 181028a0d84c ("RDMA/bnxt_re: Share a page to expose per SRQ info with userspace") Link: https://patch.msgid.link/r/20260615224751.232802-16-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 03c9a2fba68e0e1923b3bca22e61c6913cf0efce Author: Selvin Xavier Date: Mon Jun 15 15:47:50 2026 -0700 RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is disabled [ Upstream commit a57592c6392a8e333c9c2731701297a5a279313a ] No need to support the DBR related page allocations if the pacing feature is disabled. Fail the request if pacing is disabled. Fixes: ea2224857882 ("RDMA/bnxt_re: Update alloc_page uapi for pacing") Link: https://patch.msgid.link/r/20260615224751.232802-15-selvin.xavier@broadcom.com Reviewed-by: Sriharsha Basavapatna Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit da406b8b49c1dfe661a497483940d7ee781430db Author: Selvin Xavier Date: Mon Jun 15 15:47:47 2026 -0700 RDMA/bnxt_re: Avoid repeated requests to allocate WC pages [ Upstream commit 441baa79043431807115fd030d7d0bb14ed441a0 ] Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page. Fixes: eee6268421a2 ("RDMA/bnxt_re: Move the UAPI methods to a dedicated file") Fixes: 360da60d6c6e ("RDMA/bnxt_re: Enable low latency push") Link: https://patch.msgid.link/r/20260615224751.232802-12-selvin.xavier@broadcom.com Reviewed-by: Kalesh AP Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 303f6fef95df5e5316970746d861cf6daeeca77f Author: Selvin Xavier Date: Mon Jun 15 15:47:46 2026 -0700 RDMA/bnxt_re: Proper rollback if the ioremap fails [ Upstream commit 87267803a8c824616eb147c5dad7030a5db6f878 ] bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status. Fixes: 0ac20faf5d83 ("RDMA/bnxt_re: Reorg the bar mapping") Fixes: 360da60d6c6e ("RDMA/bnxt_re: Enable low latency push") Link: https://patch.msgid.link/r/20260615224751.232802-11-selvin.xavier@broadcom.com Reviewed-by: Sriharsha Basavapatna Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a59d815cbe667929b693b5fa6716a074e6a31c5b Author: Selvin Xavier Date: Mon Jun 15 15:47:45 2026 -0700 RDMA/bnxt_re: Add a max slot check for SQ [ Upstream commit dc95931b7e1326dacae547874bf38c092e5960d8 ] The variable WQE mode must be validated against the maximum slots supported by HW. The max supported value is 64K. Adding a max and min check and fail if user supplied value is more than the max supported and zero. Fixes: d8ea645d6984 ("RDMA/bnxt_re: Handle variable WQE support for user applications") Link: https://patch.msgid.link/r/20260615224751.232802-10-selvin.xavier@broadcom.com Reviewed-by: Sriharsha Basavapatna Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a65b5258b14ca9442f9fbab501bddb9e98d9477a Author: Sriharsha Basavapatna Date: Tue May 19 20:30:41 2026 +0530 RDMA/bnxt_re: Enable app allocated QPs [ Upstream commit 47b730054f05a05acd497c138bf3255a5de1a973 ] The driver supports a new comp_mask: REQ_MASK_FIXED_QUE_ATTR. The application sets this comp_mask bit in the CREATE_QP ureq to indicate direct control of the QP. The driver goes through the required processing for app allocated QPs (previous patches). Only variable WQE mode is supported for these QPs. This patch removes an unused comp_mask: BNXT_RE_QP_REQ_MASK_VAR_WQE_SQ_SLOTS Link: https://patch.msgid.link/r/20260519150041.7251-10-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna Reviewed-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Stable-dep-of: dc95931b7e13 ("RDMA/bnxt_re: Add a max slot check for SQ") Signed-off-by: Sasha Levin commit 6eceb09df972d8188e7e9bf77d2bab2d596dceac Author: Sriharsha Basavapatna Date: Tue May 19 20:30:40 2026 +0530 RDMA/bnxt_re: Support doorbells for app allocated QPs [ Upstream commit 7e812673a948395675e9893e75b0fc60d19bbf27 ] App allocated QPs can use a separate doorbell for each QP. This doorbell region can be passed through a new driver specific DBR_HANDLE attribute, during QP creation. When this attribute is set, associate the QP with the given doorbell region. While the QP holds a reference to the dbr, the dbr itself cannot be destroyed and is rejected with EBUSY error. Link: https://patch.msgid.link/r/20260519150041.7251-9-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna Reviewed-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Stable-dep-of: dc95931b7e13 ("RDMA/bnxt_re: Add a max slot check for SQ") Signed-off-by: Sasha Levin commit 2234acd1d1d29790e2a23f08782a8954be320ae1 Author: Sriharsha Basavapatna Date: Tue May 19 20:30:38 2026 +0530 RDMA/bnxt_re: Enhance dbr usecnt logic in doorbell uapis [ Upstream commit 73607410f4f1b0d5c3d0af2d70a79c265482a0e3 ] The current logic in the doorbell cleanup function is not sufficient for a change in a subsequent patch, that fails doorbell remove operation in some conditions. The cleanup should facilitate freeing of the dbr object when the caller may not retry the teardown operation (implicit teardown: process-exit/driver-removal). Extend this counter to use kref mechanism so that the dbr object gets freed (via kref callback) when there are no more references to it, rather than directly freeing it in the cleanup uapi. Link: https://patch.msgid.link/r/20260519150041.7251-7-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna Reviewed-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Stable-dep-of: dc95931b7e13 ("RDMA/bnxt_re: Add a max slot check for SQ") Signed-off-by: Sasha Levin commit 3169824fd8f44a4b6fcba45bd6397541ff0aa4a9 Author: Sriharsha Basavapatna Date: Tue May 19 20:30:36 2026 +0530 RDMA/bnxt_re: Update msn table size for app allocated QPs [ Upstream commit 9ce2a8c81c3099f68d371d040d77aab8cd1a9ed5 ] For app allocated QPs, the driver shouldn't use slots/round-up logic to compute the msn table size. The application handles this logic and computes 'sq_npsn' and passes it to the driver using a new uapi parameter. Link: https://patch.msgid.link/r/20260519150041.7251-5-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna Reviewed-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Stable-dep-of: dc95931b7e13 ("RDMA/bnxt_re: Add a max slot check for SQ") Signed-off-by: Sasha Levin commit 7605fd8bbf4d3d608a96f06e1d047775d2ec8574 Author: Sriharsha Basavapatna Date: Tue May 19 20:30:33 2026 +0530 RDMA/bnxt_re: Refactor bnxt_re_init_user_qp() [ Upstream commit 9a79dcbedcc7a0330a227f23fbd220515c61d54c ] The umem changes for CQ added a helper - bnxt_re_setup_sginfo(). Use the same helper for QP creation since we support only 4K pages for QP ring memory too. Add a new helper function bnxt_re_get_psn_bytes() to improve readability as this code will be updated in subsequent patches. Link: https://patch.msgid.link/r/20260519150041.7251-2-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna Reviewed-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Stable-dep-of: dc95931b7e13 ("RDMA/bnxt_re: Add a max slot check for SQ") Signed-off-by: Sasha Levin commit 0c403e0786768d88cabe0ccf4e45425da2fd8841 Author: Selvin Xavier Date: Mon Jun 15 15:47:44 2026 -0700 RDMA/bnxt_re: Avoid displaying the kernel pointer [ Upstream commit 7d70c704a06f620d5d421ab76bac5e225bfb4308 ] While dumping the info on MR using the rdma tool, we dump the mr_hwq which is a kernel pointer. There is no need to expose this value for end user. So avoid it. Fixes: 7363eb76b7f3 ("RDMA/bnxt_re: Support driver specific data collection using rdma tool") Link: https://patch.msgid.link/r/20260615224751.232802-9-selvin.xavier@broadcom.com Reviewed-by: Kalesh AP Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b193854675ecad43b4d69c304c1b6a90b206cc99 Author: Selvin Xavier Date: Mon Jun 15 15:47:39 2026 -0700 RDMA/bnxt_re: Free CQ toggle page after firmware teardown [ Upstream commit bb45e06f9914ca64ac95341a80a0c20bb8dd46a9 ] Free the toggle page only after firmware teardown completes so that an NQ interrupt arriving during bnxt_qplib_destroy_cq() won't write the toggle value to an already-freed page. Move free_page() after bnxt_qplib_destroy_cq. Fixes: e275919d9669 ("RDMA/bnxt_re: Share a page to expose per CQ info with userspace") Link: https://patch.msgid.link/r/20260615224751.232802-4-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0adcd67f3d6f84835be682da0153f57f5c2f8036 Author: Selvin Xavier Date: Mon Jun 15 15:47:38 2026 -0700 RDMA/bnxt_re: Free SRQ toggle page after firmware teardown [ Upstream commit 131e2918b9b0529687e67e2e58047304027f095a ] Free the toggle page only after firmware teardown completes so that an NQ interrupt arriving during bnxt_qplib_destroy_srq() won't write the toggle values to an already-freed page. Move free_page() after bnxt_qplib_destroy_srq(). Fixes: 181028a0d84c ("RDMA/bnxt_re: Share a page to expose per SRQ info with userspace") Link: https://patch.msgid.link/r/20260615224751.232802-3-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3d00b375853fbbf4157ad092884b4ed9a49429c1 Author: Selvin Xavier Date: Mon Jun 15 15:47:37 2026 -0700 RDMA/bnxt_re: Initialize dpi variable to zero [ Upstream commit 978b27d6ce538bb832ccd69e45802824e4301c4b ] dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0. Fixes: eee6268421a2 ("RDMA/bnxt_re: Move the UAPI methods to a dedicated file") Fixes: 360da60d6c6e ("RDMA/bnxt_re: Enable low latency push") Link: https://patch.msgid.link/r/20260615224751.232802-2-selvin.xavier@broadcom.com Reviewed-by: Anantha Prabhu Signed-off-by: Kalesh AP Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5126f099295c72a3a62bd4bf98c47add909cb6fe Author: Brett Creeley Date: Sun Jun 14 13:52:59 2026 -0700 ionic: Fix check in ionic_get_link_ext_stats [ Upstream commit 7678e69079c10b2fb10977f28f44ddb22971ea5b ] The current check will fail if SR-IOV is not initialized for the physical function; this is because is_physfn is 0 if sriov_init() isn't run or fails. Change the check that prevents getting the link down count to use is_virtfn instead so that VFs don't get this functionality, which was the original intent. Fixes: 132b4ebfa090 ("ionic: add support for ethtool extended stat link_down_count") Signed-off-by: Brett Creeley Signed-off-by: Eric Joyner Link: https://patch.msgid.link/20260614205303.48088-2-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d01d4cfc806a1c56b6ba694fc4ca0948f7b4d7ed Author: Selvamani Rajagopal Date: Thu Jun 11 14:55:40 2026 -0700 net: ethernet: oa_tc6: Remove FCS size in RX frame [ Upstream commit a5a1d11dd3729146abe7420b874bab15870a42b4 ] OA TC6 MAC-PHY appends FCS to the incoming frame. It must be removed from the frame before being passed to the stack. With FCS in the frame, many applications, like ping or any application that uses IP layer may work as they may carry the packet size information in the protocol. Application like ptp4l, particularly if it uses layer 2 for its communication, it will fail with "bad message" due to the extra 4 bytes added by the presence of FCS. Fixes: d70a0d8f2f2d ("net: ethernet: oa_tc6: implement receive path to receive rx ethernet frames") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260611-level-trigger-v5-3-4533a9e85ce2@onsemi.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 785e3765bf9a5dd9af871988569403159e57782e Author: Meghana Malladi Date: Fri Jun 12 00:27:43 2026 +0530 net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload mode [ Upstream commit f9691288413ceb4fc72f3ccc4d8e42adf66eb28d ] emac_xsk_xmit_zc() has the same issue as the fixed emac_xmit_xdp_frame(): it always sets the CPPI5 descriptor destination tag to emac->port_id, which directs the PRU firmware to transmit on only one slave port in HSR mode, breaking redundancy. Apply the same fix: in HSR offload mode when NETIF_F_HW_HSR_DUP is set, use PRUETH_UNDIRECTED_PKT_DST_TAG (port 0) so the PRU duplicates frames to both ports. Also set PRUETH_UNDIRECTED_PKT_TAG_INS when NETIF_F_HW_HSR_TAG_INS is set so the PRU re-inserts the HSR sequence tag that was stripped by the PRU on RX before the XDP program saw the frame. This ensures XSK XDP_TX frames in HSR mode are treated identically to skb TX via hsr0. Fixes: 8756ef2eb078 ("net: ti: icssg-prueth: Add AF_XDP zero copy for TX") Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20260611185744.2498070-4-m-malladi@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 40a91dcc62607019e36488c718218cd6f4eb9d3b Author: Meghana Malladi Date: Fri Jun 12 00:27:42 2026 +0530 net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode [ Upstream commit bcbf73d98195577a89e788179843f6d0c66244a5 ] emac_xmit_xdp_frame() always sets the CPPI5 descriptor destination tag to emac->port_id, which directs the PRU firmware to transmit the frame on that specific slave port only. In HSR offload mode this bypasses the firmware's HSR duplication logic: the frame goes out on one ring leg and never appears on the other, breaking HSR redundancy for XDP_TX paths. icssg_ndo_start_xmit() already handles this correctly: when HSR offload mode is active and NETIF_F_HW_HSR_DUP is set it substitutes PRUETH_UNDIRECTED_PKT_DST_TAG (port 0) so the PRU duplicates the frame to both slave ports. It also sets PRUETH_UNDIRECTED_PKT_TAG_INS in epib[1] when NETIF_F_HW_HSR_TAG_INS is set so the PRU inserts the HSR sequence tag, which XDP_TX frames lack (the tag is stripped by the PRU on RX before the frame reaches the XDP program). Apply the same logic in emac_xmit_xdp_frame() so XDP_TX frames in HSR mode are treated identically to skb TX via hsr0. Fixes: 62aa3246f462 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20260611185744.2498070-3-m-malladi@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b478a6ffda4efd8b14f6a947d474aed60e817624 Author: Meghana Malladi Date: Fri Jun 12 00:27:41 2026 +0530 net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition [ Upstream commit dfb787f7d157f97ba91344b584d33481f572530e ] emac_rx_packet_zc() calls prueth_rx_alloc_zc() with count (frames received in the current NAPI poll) as the allocation budget. Two problems arise from this: 1. When the CPPI5 descriptor pool is exhausted (avail_desc == 0, FDQ already holds the maximum number of descriptors), count > 0 still triggers allocation attempts that all fail, spamming the kernel log with "rx push: failed to allocate descriptor" at high packet rates. 2. The XSK wakeup condition "ret < count" is wrong when avail_desc is zero: ret == 0 and count can be up to 64, so the condition is always true. This causes ~200 spurious ndo_xsk_wakeup() calls per second even when the FDQ is already full, wasting CPU cycles in repeated NAPI invocations that process zero frames. Fix both by introducing alloc_budget = min(budget, avail_desc): - When avail_desc == 0 no allocation is attempted, avoiding pool exhaustion errors. The wakeup condition "ret < alloc_budget" evaluates to 0 < 0 == false, correctly clearing the wakeup flag so the hardware IRQ re-arms NAPI without spurious kicks. - In steady state avail_desc == count <= budget, so alloc_budget == count and behaviour is unchanged. - After a dry-ring stall (count == 0, avail_desc > 0), alloc_budget > 0 causes new descriptors to be posted to the FDQ so the hardware can resume receiving immediately. Fixes: 7a64bb388df3 ("net: ti: icssg-prueth: Add AF_XDP zero copy for RX") Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20260611185744.2498070-2-m-malladi@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad262d2b96beeae434493a2041eab7e0cc155008 Author: Wayen.Yan Date: Sat Jun 13 08:23:12 2026 +0800 net: airoha: Fix always-true condition in PPE1 queue reservation loop [ Upstream commit c66f8511a8109fa50767941b26d3623e316fde02 ] In airoha_fe_pse_ports_init(), the inner condition for PPE1 queue reservation is identical to the for-loop bound, making it always true and the else branch dead code: for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_PPE1]; q++) { if (q < pse_port_num_queues[FE_PSE_PORT_PPE1]) /* always true */ set RSV_PAGES; else set 0; /* unreachable */ } The intended behavior is to reserve pages only for the first half of the queues, matching the PPE2 implementation on line 334 which correctly uses the /2 divisor. Fix the PPE1 condition accordingly. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Wayen.Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/6a2ca3de.ad59c0a6.147df9.2ac1@mx.google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a210791f33345aa87187f7d7a9f3b9b7f4a28e6d Author: Eric Dumazet Date: Fri Jun 12 16:25:17 2026 +0000 tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) [ Upstream commit 2bf43d0e2e6a27d52a7d624e2d6b9116972e8a22 ] When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean "any MSS". Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes") Reported-by: syzbot+ebdb22d461c904fc3cb2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a2c3193.8812e0fc.3c3fa4.0001.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612162517.83394-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35e0297a93c3c34a3924eeef816c03504e3ab5c5 Author: Eric Dumazet Date: Fri Jun 12 13:59:49 2026 +0000 tipc: fix UAF in tipc_l2_send_msg() [ Upstream commit f4c3d89fc986b0da196ddfc6cfe0ea5d5d08bec6 ] Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 ("tipc: make bearer packet filtering generic") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). Fixes: 282b3a056225 ("tipc: send out RESET immediately when link goes down") https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u Reported-by: syzbot+64ec81389cbad56a8c35@syzkaller.appspotmail.com Signed-off-by: Eric Dumazet Cc: Jon Maloy Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260612135949.4010482-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2fb2ef76008e1aa16326521d43ef65504d6f042 Author: Gui-Dong Han Date: Fri May 29 11:34:06 2026 +0800 KEYS: Use acquire when reading state in keyring search [ Upstream commit c1201b37f666f6466ab1fd3a381c2b7a4b7e9fee ] The negative-key race fix added release/acquire ordering for key use. Publish payload before state; read state before payload. keyring_search_iterator() still uses READ_ONCE() before match callbacks. An asymmetric match callback calls asymmetric_key_ids(), which reads key->payload.data[asym_key_ids]. Use key_read_state() there to complete that ordering. Fixes: 363b02dab09b ("KEYS: Fix race between updating and finding a negative key") Signed-off-by: Gui-Dong Han Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260529033406.20673-1-hanguidong02@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit c893bfb0d696d9f9f726d1b8f16d50cc78bfc9e5 Author: Aboorva Devarajan Date: Fri Jun 5 13:59:12 2026 +0530 powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus [ Upstream commit 5c86f1c1f972761a04bf22f4c0618d1aa714185b ] kexec_prepare_cpus_wait() calls get_cpu() internally to obtain the current CPU id. kexec_prepare_cpus() calls kexec_prepare_cpus_wait() twice -- once for KEXEC_STATE_IRQS_OFF and once for KEXEC_STATE_REAL_MODE -- but only issues a single put_cpu() at the end, leaving preempt_count elevated by one extra nesting level. In practice the imbalance does not trigger a 'scheduling while atomic' splat because the kexec path is a one-way trip: IRQs are already disabled, no schedule() occurs after the leak, and default_machine_kexec() overwrites preempt_count with HARDIRQ_OFFSET before jumping into kexec_sequence() which never returns. However the bookkeeping is still wrong. kexec_prepare_cpus() calls local_irq_disable()/hard_irq_disable() before invoking kexec_prepare_cpus_wait(), so the CPU is already pinned and the get_cpu()/put_cpu() preempt_disable() bracketing is unnecessary. Only the current CPU id is needed, so replace get_cpu() with raw_smp_processor_id() and drop the now-unneeded put_cpu(). Fixes: 1fc711f7ffb0 ("powerpc/kexec: Fix race in kexec shutdown") Signed-off-by: Aboorva Devarajan Reviewed-by: Shrikanth Hegde Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260605082912.305100-4-aboorvad@linux.ibm.com Signed-off-by: Sasha Levin commit e4e69cee0b01e6aa1a8794154136698b8ed5bb28 Author: Aboorva Devarajan Date: Fri Jun 5 13:59:11 2026 +0530 powerpc/powernv: fix preempt count leak in pnv_kexec_wait_secondaries_down [ Upstream commit 0ecd26e93e698c8327521910fc6296f5b84a4b92 ] pnv_kexec_wait_secondaries_down() calls get_cpu() to obtain the current CPU id but never calls the matching put_cpu(), leaking one preempt_disable() nesting level on every invocation. In practice the imbalance does not trigger a visible splat because the kexec teardown path is a one-way trip: IRQs are already disabled, no schedule() occurs after the leak, and default_machine_kexec() overwrites preempt_count with HARDIRQ_OFFSET before jumping into kexec_sequence() which never returns. However the bookkeeping is still wrong. The function only needs the current CPU id, and this path runs with interrupts disabled and the CPU pinned, so the preempt_disable() side-effect of get_cpu() is unnecessary. Replace it with raw_smp_processor_id(). Fixes: 298b34d7d578 ("powerpc/powernv: Fix kexec races going back to OPAL") Signed-off-by: Aboorva Devarajan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260605082912.305100-3-aboorvad@linux.ibm.com Signed-off-by: Sasha Levin commit b504fd953664c3f4d176ae8cb594adb3fda9d577 Author: Aboorva Devarajan Date: Fri Jun 5 13:59:10 2026 +0530 powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del [ Upstream commit 81e3a86030462824a67d697739cf3f387f4ba350 ] fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events) at the 'out:' label, but only calls the matching get_cpu_var() after the 'i < 0' early-return check. When event->hw.idx is negative the function jumps to 'out:' without having taken get_cpu_var(), and the trailing put_cpu_var() then issues an unmatched preempt_enable(), underflowing preempt_count. On a CONFIG_PREEMPT=y kernel preempt_count would underflow and eventually present as a 'scheduling while atomic' BUG. Move put_cpu_var() to pair with get_cpu_var() so the percpu access is correctly bracketed and the 'out:' label only handles perf_pmu_enable. Fixes: a11106544f33 ("powerpc/perf: e500 support") Reviewed-by: Shrikanth Hegde Signed-off-by: Aboorva Devarajan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260605082912.305100-2-aboorvad@linux.ibm.com Signed-off-by: Sasha Levin commit 038f068cced8e9c49e8c419f3112d909ad366a3a Author: Yadan Fan Date: Mon May 25 12:04:36 2026 +0800 MIPS: mm: Fix out-of-bounds write in maar_res_walk() [ Upstream commit 1b001b16bc88f3f7817e228acfd91ee01bdcfcce ] maar_res_walk() uses wi->num_cfg as the index into the fixed-size wi->cfg array, but checks whether the array is full only after it has filled the selected entry. If walk_system_ram_range() reports more than 16 memory ranges, the overflow call writes one struct maar_config past the end of the array before WARN_ON() prevents num_cfg from advancing. Move the full-array check before taking the array slot and return non-zero when the scratch array is full, so walk_system_ram_range() terminates the walk instead of invoking the callback for further ranges. Fixes: a5718fe8f70f ("MIPS: mm: Drop boot_mem_map") Signed-off-by: Yadan Fan Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e09f7bd7273928b4089e6b71f8e992f2b356ca1b Author: Sechang Lim Date: Mon Jun 15 10:19:58 2026 +0800 bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check [ Upstream commit a48802fb2cd2d1e23651989f8ff4d15e9d5dad54 ] start and len are u32, so u64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check if (start >= offset + l || last > msg->sg.size) return -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop. Fixes: 7246d8ed4dcc ("bpf: helper to pop data from messages") Reviewed-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Reviewed-by: Kuniyuki Iwashima Signed-off-by: Sechang Lim Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260615021959.140010-6-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 39d44ed6904bfa9a1c6d0538672dd50c7b85520e Author: Kuniyuki Iwashima Date: Mon Jun 15 10:19:57 2026 +0800 sockmap: Fix use-after-free in udp_bpf_recvmsg() [ Upstream commit c010995b29c8939c6aa69e3cb26f8dbee163d156 ] syzbot reported use-after-free of struct sk_msg in sk_msg_recvmsg(). [0] sk_msg_recvmsg() peeks sk_msg from psock->ingress_msg under a lock, but its processing is lockless. Thus, sk_msg_recvmsg() must be serialised by callers, otherwise multiple threads could touch the same sk_msg. For example, TCP uses lock_sock(), and AF_UNIX uses unix_sk(sk)->iolock. Initially, udp_bpf_recvmsg() had used lock_sock(), but the cited commit removed it. Let's serialise sk_msg_recvmsg() with lock_sock() in udp_bpf_recvmsg(). Note that holding spin_lock_bh(&sk->sk_receive_queue.lock) is not an option due to copy_page_to_iter() in sk_msg_recvmsg(). [0]: BUG: KASAN: slab-use-after-free in sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c:428 Read of size 4 at addr ffff88814cdcf000 by task syz.0.24/6020 CPU: 1 UID: 0 PID: 6020 Comm: syz.0.24 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c:428 udp_bpf_recvmsg+0x4bd/0xe00 net/ipv4/udp_bpf.c:84 inet_recvmsg+0x260/0x270 net/ipv4/af_inet.c:891 sock_recvmsg_nosec net/socket.c:1078 [inline] sock_recvmsg+0x1a8/0x270 net/socket.c:1100 ____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2812 ___sys_recvmsg+0x215/0x590 net/socket.c:2854 do_recvmmsg+0x334/0x800 net/socket.c:2949 __sys_recvmmsg net/socket.c:3023 [inline] __do_sys_recvmmsg net/socket.c:3046 [inline] __se_sys_recvmmsg net/socket.c:3039 [inline] __x64_sys_recvmmsg+0x198/0x250 net/socket.c:3039 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb319f9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb31ad97028 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 00007fb31a216090 RCX: 00007fb319f9aeb9 RDX: 0000000000000001 RSI: 0000200000000400 RDI: 0000000000000004 RBP: 00007fb31a008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000040000021 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fb31a216128 R14: 00007fb31a216090 R15: 00007ffe21dd0a98 Allocated by task 6019: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __kmalloc_cache_noprof+0x3d1/0x6e0 mm/slub.c:5780 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] alloc_sk_msg net/core/skmsg.c:510 [inline] sk_psock_skb_ingress_self+0x60/0x350 net/core/skmsg.c:612 sk_psock_verdict_apply net/core/skmsg.c:1038 [inline] sk_psock_verdict_recv+0x7d9/0x8d0 net/core/skmsg.c:1236 udp_read_skb+0x73e/0x7e0 net/ipv4/udp.c:2045 sk_psock_verdict_data_ready+0x12d/0x550 net/core/skmsg.c:1257 __udp_enqueue_schedule_skb+0xc54/0x10b0 net/ipv4/udp.c:1789 __udp_queue_rcv_skb net/ipv4/udp.c:2346 [inline] udp_queue_rcv_one_skb+0xac5/0x19c0 net/ipv4/udp.c:2475 __udp4_lib_mcast_deliver+0xc06/0xcf0 net/ipv4/udp.c:2585 __udp4_lib_rcv+0x10f6/0x2620 net/ipv4/udp.c:2724 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x336/0x3c0 include/linux/netfilter.h:318 dst_input include/net/dst.h:474 [inline] ip_sublist_rcv_finish+0x221/0x2a0 net/ipv4/ip_input.c:584 ip_list_rcv_finish net/ipv4/ip_input.c:628 [inline] ip_sublist_rcv+0x5c6/0xa70 net/ipv4/ip_input.c:644 ip_list_rcv+0x3f1/0x450 net/ipv4/ip_input.c:678 __netif_receive_skb_list_ptype net/core/dev.c:6195 [inline] __netif_receive_skb_list_core+0x7e5/0x810 net/core/dev.c:6242 __netif_receive_skb_list net/core/dev.c:6294 [inline] netif_receive_skb_list_internal+0x995/0xcf0 net/core/dev.c:6385 netif_receive_skb_list+0x54/0x410 net/core/dev.c:6437 xdp_recv_frames net/bpf/test_run.c:269 [inline] xdp_test_run_batch net/bpf/test_run.c:350 [inline] bpf_test_run_xdp_live+0x1946/0x1cf0 net/bpf/test_run.c:379 bpf_prog_test_run_xdp+0x81c/0x1160 net/bpf/test_run.c:1396 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x5cb/0x920 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6021: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free mm/slub.c:6674 [inline] kfree+0x1be/0x650 mm/slub.c:6882 kfree_sk_msg include/linux/skmsg.h:385 [inline] sk_msg_recvmsg+0xaa8/0xc30 net/core/skmsg.c:483 udp_bpf_recvmsg+0x4bd/0xe00 net/ipv4/udp_bpf.c:84 inet_recvmsg+0x260/0x270 net/ipv4/af_inet.c:891 sock_recvmsg_nosec net/socket.c:1078 [inline] sock_recvmsg+0x1a8/0x270 net/socket.c:1100 ____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2812 ___sys_recvmsg+0x215/0x590 net/socket.c:2854 do_recvmmsg+0x334/0x800 net/socket.c:2949 __sys_recvmmsg net/socket.c:3023 [inline] __do_sys_recvmmsg net/socket.c:3046 [inline] __se_sys_recvmmsg net/socket.c:3039 [inline] __x64_sys_recvmmsg+0x198/0x250 net/socket.c:3039 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 9f2470fbc4cb ("skmsg: Improve udp_bpf_recvmsg() accuracy") Reported-by: syzbot+9307c991a6d07ce6e6d8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69922ac9.a70a0220.2c38d7.00e0.GAE@google.com/ Reviewed-by: Jiayuan Chen Reviewed-by: Jakub Sitnicki Reviewed-by: Emil Tsalapatis Signed-off-by: Kuniyuki Iwashima Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260615021959.140010-5-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bd004716ba75fed6d185795c85cdc92540ebeaab Author: Weiming Shi Date: Mon Jun 15 10:19:54 2026 +0800 bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() [ Upstream commit 0c0a8ed85349dae298712d79cb276acfeb794d82 ] When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation. Link: https://lore.kernel.org/all/20260424155913.A19FDC19425@smtp.kernel.org Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data") Tested-by: Xiang Mei Tested-by: Xinyu Ma Reviewed-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Reviewed-by: Kuniyuki Iwashima Signed-off-by: Weiming Shi Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260615021959.140010-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 478c7f68ef254a59de812a12a47b16d853685abf Author: Al Viro Date: Wed Feb 11 15:11:28 2026 -0500 udf: fix nls leak on udf_fill_super() failure [ Upstream commit 462bdd08fbdf41db223c6117d907c8fd68d666ea ] On all failure exits that go to error_out there we have already moved the nls reference from uopt->nls_map to sbi->s_nls_map, leaving NULL behind. Fixes: c4e89cc674ac ("udf: convert to new mount API") Acked-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c12e3c9e5224a51d14914467d846315f5da0b241 Author: Leon Hwang Date: Sun Jun 14 00:24:42 2026 +0800 bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket [ Upstream commit ca0f587c029afa66227f7b932450b1c417403394 ] When TCP over IPv4 via INET6 API, bpf_get/setsockopt with ipv4 will fail, because sk->sk_family is AF_INET6. With ipv6 will success, not take effect, because inet_csk(sk)->icsk_af_ops is ipv6_mapped and use ip_queue_xmit, inet_sk(sk)->tos. To relax this restriction, allow getting/setting tos for those possible ipv4-mapped ipv6 sockets. Fixes: ee7f1e1302f5 ("bpf: Change bpf_setsockopt(SOL_IP) to reuse do_ip_setsockopt()") Signed-off-by: Feng Zhou Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260613162443.60515-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e68343ee3c131cd84ffec5ae29c5d91127b8bb67 Author: Leo Yan Date: Tue Jun 2 15:47:15 2026 +0100 selftests/bpf: Initialize operation name before use [ Upstream commit 55ffbe8a15b1254f44d56952fb425a10e3f15c31 ] ASAN reports stack-buffer-overflow due to the uninitialized op_name. Initialize it to fix the issue. Fixes: 054b6c7866c7 ("selftests/bpf: Add verifier log tests for BPF_BTF_LOAD command") Signed-off-by: Leo Yan Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260602-tools_build_fix_zero_init_bpf_only-v2-6-c76e5250ea1c@arm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 85100de4f473173e96645d5a6c00516fab61e379 Author: Jiri Olsa Date: Thu Jun 11 13:42:30 2026 +0200 selftests/bpf: Fix typo in verify_umulti_link_info [ Upstream commit df29003c55115737a8fb4f8a60c6c2bba4c4a484 ] We verify info.uprobe_multi.flags against wrong kprobe-multi flag (BPF_F_KPROBE_MULTI_RETURN). It's the same value as the correct flag (BPF_F_UPROBE_MULTI_RETURN), so there's not functional change. Fixes: 147c69307bcf ("selftests/bpf: Add link_info test for uprobe_multi link") Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260611114230.950379-8-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c6d51ad36490013ee9df94a372d3bf794bd304d1 Author: Jiri Olsa Date: Thu Jun 11 13:42:24 2026 +0200 bpf: Guard __get_user acesss with access_ok for uprobe_multi data [ Upstream commit 4d87a251d45b4a95eb4c0abcfab809c9f231258a ] As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it. [1] https://lore.kernel.org/bpf/20260610145235.CB1441F00893@smtp.kernel.org/ Fixes: 0b779b61f651 ("bpf: Add cookies support for uprobe_multi link") Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260611114230.950379-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 590d696f846a60ee0c2ff2618fcbbe0e6e7b72b8 Author: Nathan Chancellor Date: Mon Jun 1 19:46:26 2026 -0700 btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues() [ Upstream commit c7703f05d85f71153f5e241184397bc34da305e3 ] After commit 21c05ca88a54 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present"), there is a warning from the btrfs-qgroup-rescan workqueue at run time: workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND. WQ_PERCPU is included in ordered_flags after commit 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users") and WQ_UNBOUND is set in alloc_ordered_workqueue(), which btrfs_alloc_ordered_workqueue() calls. Drop WQ_PERCPU from ordered_flags, as alloc_ordered_workqueue() notes that only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful. Fixes: 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users") Fixes: 21c05ca88a54 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present") Signed-off-by: Nathan Chancellor Reviewed-by: Breno Leitao Acked-by: Marco Crivellari Acked-by: David Sterba Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 2bc610c9db5d0df660a726d068594d2db8977792 Author: Huiwen He Date: Mon Jun 8 23:57:29 2026 +0800 smb/client: always return a value for FS_IOC_GETFLAGS [ Upstream commit 7acbaa16b99edaf8ef432229d4b7a6f3b666767d ] Currently, repeated lsattr calls on a regular CIFS file without the compressed attribute may show random flags: $ touch test.bin $ lsattr test.bin s-S-ia-A-EjI---------m test.bin $ lsattr test.bin ------d-cEjI---------m test.bin The lsattr reproducer depends on the previous contents of its userspace buffer, so it may not reproduce on every setup. A deterministic reproducer is to initialize the ioctl argument before FS_IOC_GETFLAGS on a file without the compressed attribute: int flags = 0x7fffffff; ioctl(fd, FS_IOC_GETFLAGS, &flags); On an affected kernel, flags remains 0x7fffffff. With the fix, it is set to 0. This happens because when the cached inode does not have the compressed bit set, the CIFS fallback path in FS_IOC_GETFLAGS returns success without calling put_user() to write the zero flags value into the user buffer. As a result, the caller observes stale contents from its own buffer. Fix this by always writing the visible flags value back to the user buffer before returning success, even when the value is zero. Fixes: 64a5cfa6db94 ("Allow setting per-file compression via SMB2/3") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7839f1817a0cb6c4ed5cfe25d04845c43380a129 Author: Jian Zhang Date: Tue May 19 18:44:22 2026 +0800 cifs: remove all cifs files before kill super [ Upstream commit 6d9a4aaaa8b2612b5ef9d581e2f286a458b71ee1 ] Cifs files may be put into fileinfo_put_wq during umounting cifs. After umount done, cifsFileInfo_put_final is called, which cause following BUG: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 134.222152] list_lru_add+0x64/0x1a0 [ 134.222399] ? cifs_put_tcon+0x171/0x340 [cifs] [ 134.222772] d_lru_add+0x44/0x60 [ 134.222997] dput+0x1fc/0x210 [ 134.223213] cifsFileInfo_put_final+0x11a/0x140 [cifs] [ 134.223576] process_one_work+0x17c/0x320 [ 134.223843] worker_thread+0x188/0x280 [ 134.224084] ? __pfx_worker_thread+0x10/0x10 [ 134.224366] kthread+0xcc/0x100 [ 134.224576] ? __pfx_kthread+0x10/0x10 [ 134.224827] ret_from_fork+0x30/0x50 [ 134.225063] ? __pfx_kthread+0x10/0x10 [ 134.225328] ret_from_fork_asm+0x1b/0x30 This can be reproduce by following: unshare -n bash -c " mkdir -p ${CIFS_MNT} ip netns attach root 1 ip link add eth0 type veth peer veth0 netns root ip link set eth0 up ip -n root link set veth0 up ip addr add 192.168.0.2/24 dev eth0 ip -n root addr add 192.168.0.1/24 dev veth0 ip route add default via 192.168.0.1 dev eth0 ip netns exec root sysctl net.ipv4.ip_forward=1 ip netns exec root iptables -t nat -A POSTROUTING -s 192.168.0.2 -o ${DEV} -j MASQUERADE mount -t cifs ${CIFS_PATH} ${CIFS_MNT} -o vers=3.0,sec=ntlmssp,credentials=${CIFS_CRED},rsize=65536,wsize=65536,cache=none,echo_interval=1 touch ${CIFS_MNT}/a.txt ip netns exec root iptables -t nat -D POSTROUTING -s 192.168.0.2 -o ${DEV} -j MASQUERADE " umount ${CIFS_MNT} Fixes: 340cea84f691 ("cifs: open files should not hold ref on superblock") Signed-off-by: Jian Zhang Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 018b3c8248f5d5f335d28f9cbc04abd01b99ecab Author: Henrique Carvalho Date: Wed May 27 09:26:42 2026 -0300 smb: client: fix conflicting option validation for new mount API [ Upstream commit 10ce03879f935f756bc8a386b3fa3a1c7264d950 ] Apply conflicting option validation consistently across all the new mount API paths, for both mount and remount. Some checks were only applied during initial mount validation, while others were handled during option parsing, causing mount and remount/reconfigure to behave differently. Move the conflicting option checks into smb3_handle_conflicting_options() and call it from the common validation paths, including for multichannel/max_channels handling. Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api") Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b8ca5fcc3182a701b48c6d9ddace4da223efd358 Author: Takashi Iwai Date: Sun Jun 14 11:05:05 2026 +0200 ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait() [ Upstream commit b113a891252c3fa4fab11ec8c2894a22ecaf278c ] snd_power_ref_and_wait() takes the power refcount and doesn't leave it no matter whether it returns an error or not. However, the majority of callers don't expect but just returns without unreferencing in the caller side upon errors. For addressing the potential refcount unbalance, rather correct the behavior of snd_power_ref_wait() to unreference upon returning an error. Note that the problem above is likely negligible; the function returns an error only when the sound card is being shutdown, hence it doesn't matter about the power refcount any longer at such a state. Fixes: e94fdbd7b25d ("ALSA: control: Track in-flight control read/write/tlv accesses") Reported-by: WenTao Liang Closes: https://lore.kernel.org/20260612022121.14329-1-vulab@iscas.ac.cn Link: https://patch.msgid.link/20260614090507.772540-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1e8ff78520d96b235021b0910b4fa33b3e82af11 Author: Alice Mikityanska Date: Thu Jun 11 21:29:46 2026 +0200 geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE [ Upstream commit 2319688890d97c63da423a3c57c23b4ab5952dfc ] GRO_LEGACY_MAX_SIZE = 65536; total_len being 65536 is too big to fit into a u16. As can be seen in skb_gro_receive, packets bigger or equal to gro_max_size (or GRO_LEGACY_MAX_SIZE) are dropped with -E2BIG. Apply the same boundary to geneve_post_decap_hint to avoid writing 65536 to a 16-bit iph->tot_len field with an overflow. Fixes: fd0dd796576e ("geneve: use GRO hint option in the RX path") Signed-off-by: Alice Mikityanska Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260611192955.604661-3-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit edf234f71fb327792196f813048ab8f5bd3bb712 Author: Pablo Neira Ayuso Date: Wed Jun 10 00:03:19 2026 +0200 netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use them [ Upstream commit 2354e975932dabb06fad239f07a3b68fd1809737 ] Update nft_dup and nft_fwd to use the nf_dev_xmit_recursion() helpers. This patch also disables BH when transmitting the skb to address a possible migration to different CPU leading to imbalanced decrementation of the recursion counters. This is modeled after Florian Westphal's dev_xmit_recursion*() API available since commit 97cdcf37b57e ("net: place xmit recursion in softnet data") according to its current state in the tree. Fixes: 1d47b55b36d2 ("netfilter: nft_fwd_netdev: use recursion counter in neigh egress path") Fixes: f37ad9127039 ("netfilter: nf_dup_netdev: Move the recursion counter struct netdev_xmit") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit db50e2d289b668c96ea8334f68bcebdd7a5932ef Author: Florian Westphal Date: Fri Jun 5 15:11:19 2026 +0200 netfilter: nf_conncount: callers must hold rcu read lock [ Upstream commit 64d7d5abe2160bba369b4a8f06bdf5630573bab0 ] rcu_derefence_raw() should not have been used here, it concealed this bug. Its used because struct rb_node lacks __rcu annotated pointers, so plain rcu_derefence causes sparse warnings. The major tradeoff is that rcu_derefence_raw() doesn't warn when the caller isn't in a rcu read section. Extend the rcu read lock scope accordingly and cause sparse warnings, those warnings are the lesser evil. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Closes: https://sashiko.dev/#/patchset/20260603230610.7900-1-fw%40strlen.de Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1c4c35fb68d520241f7d9f1c356b5e2370fd8364 Author: Cen Zhang Date: Sun Jun 14 08:48:01 2026 +0800 ALSA: seq: avoid stale FIFO cells during resize [ Upstream commit e546128291f8d688dcb931827e2efd2aa6c0734d ] snd_seq_fifo_resize() still needs to publish the replacement pool before it waits for FIFO users. A blocking snd_seq_read() holds f->use_lock while it sleeps, so concurrent senders must be able to queue to the new pool and wake that reader instead of failing against a closing old pool. However, snd_seq_fifo_event_in() duplicates an event before it takes f->lock, and snd_seq_read() can dequeue a cell and later call snd_seq_fifo_cell_putback() if copy_to_user() or snd_seq_expand_var_event() fails. If resize swaps f->pool and detaches oldhead in between, either path can relink an old-pool cell after the snapshot. That stale cell sits outside the drained oldhead list, keeps oldpool->counter elevated, and can leave snd_seq_pool_delete() waiting for the retired pool to drain. Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(), but reject stale cells before any FIFO relink. Revalidate event-in cells under f->lock and retry them against the published replacement pool, and free stale putback cells instead of linking them back into the FIFO. The buggy scenario involves two paths, with each column showing the order within that path: resize path: relink path: 1. Allocate newpool. 1. Take f->use_lock. 2. Swap f->pool to newpool and 2. Duplicate or dequeue an old-pool detach oldhead. cell before oldpool closes. 3. Mark oldpool closing and 3. Reach a later relink point after wait for FIFO users. resize published newpool. 4. Free oldhead and delete 4. Relink the old-pool cell after oldpool. resize detached oldhead. 5. Drop f->use_lock. The reproducer reports a resize ioctl blocked in the expected pool teardown path: signal: resize iteration=98 target_pool=4 exceeded 250ms (elapsed=251ms) diagnostic: resize_tid=651 wchan=snd_seq_pool_done diagnostic: resize_tid=651 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f A second run with larger pools hit the same target path: signal: resize iteration=32 target_pool=64 exceeded 250ms (elapsed=251ms) diagnostic: resize_tid=663 wchan=snd_seq_pool_done diagnostic: resize_tid=663 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 2d7d54002e39 ("ALSA: seq: Fix race during FIFO resize") Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260614004801.3507773-2-zzzccc427@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 43e10709b1ba288bcbabb9b9cb6e518b2a5d8506 Author: Cen Zhang Date: Sun Jun 14 08:48:00 2026 +0800 ALSA: seq: oss: Serialize readq reset state with q->lock [ Upstream commit 49ce92d207820f588b0406add82f053decfbe5d9 ] snd_seq_oss_readq_clear() resets qlen, head, and tail without q->lock even though the normal reader and producer paths serialize the same ring state under that spinlock. A reset can therefore race snd_seq_oss_readq_free() or snd_seq_oss_readq_put_event() and leave stale records in the queue, drop freshly queued ones, or report the wrong readiness after wakeup. KCSAN reports a data race between snd_seq_oss_readq_clear() and snd_seq_oss_readq_free(). Take q->lock while clearing the ring and resetting input_time. Factor the enqueue logic into a caller-locked helper so snd_seq_oss_readq_put_timestamp() updates its suppression state under the same lock instead of racing the reset path. The buggy scenario involves two paths, with each column showing the order within that path: reset path: locked readq updater: 1. snd_seq_oss_reset() or 1. A reader or callback producer release reaches takes q->lock on the same queue. snd_seq_oss_readq_clear(). 2. snd_seq_oss_readq_clear() 2. The updater tests or modifies resets qlen, head, tail, qlen, head, and tail. and input_time. 3. snd_seq_oss_readq_clear() 3. The updater completes its wakes sleepers on read-modify-write sequence. q->midi_sleep. 4. Without q->lock, the reset 4. The resulting ring state drives can overlap the locked later reads and readiness. update. KCSAN reports: BUG: KCSAN: data-race in snd_seq_oss_readq_clear / snd_seq_oss_readq_free write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0: snd_seq_oss_readq_free+0x6c/0x80 snd_seq_oss_read+0xcb/0x250 odev_read+0x38/0x60 vfs_read+0xff/0x600 ksys_read+0xb4/0x140 __x64_sys_read+0x46/0x60 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1: snd_seq_oss_readq_clear+0x1f/0x90 snd_seq_oss_reset+0xa7/0xf0 snd_seq_oss_ioctl+0x6f6/0x7e0 odev_ioctl+0x56/0xc0 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000001 -> 0x00000000 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260614004801.3507773-1-zzzccc427@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9684fff87124b201e11dea01ded9173025359a0f Author: Runyu Xiao Date: Thu Jun 11 13:35:43 2026 +0800 kcm: use WRITE_ONCE() when changing lower socket callbacks [ Upstream commit 47186409c092cd7dd70350999186c700233e854d ] kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611053543.2429462-1-runyu.xiao@seu.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6b638db5ec068de99ef5e3c190b80327f6e919ce Author: Wayen.Yan Date: Fri Jun 12 07:09:56 2026 +0800 net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries [ Upstream commit 1c3a77471afbb3981af28f7f7c8b2487558e4b00 ] In airoha_ppe_debugfs_foe_show(), the second switch statement falls through from PPE_PKT_TYPE_IPV4_HNAPT/DSLITE to PPE_PKT_TYPE_IPV4_ROUTE, accessing hwe->ipv4.new_tuple for all three types. However, IPv4 ROUTE (3-tuple) entries do not contain a valid new_tuple — this field is only meaningful for NATted flows (HNAPT/DSLITE). For ROUTE entries, the memory at the new_tuple offset holds routing information, not NAT data, so displaying "new=" produces garbage output. Display new_tuple only for HNAPT and DSLITE, and let IPV4_ROUTE fall through to the default case. Fixes: 3fe15c640f38 ("net: airoha: Introduce PPE debugfs support") Link: https://lore.kernel.org/6a2b40ea.4dd82583.3a5c46.e5a2@mx.google.com Signed-off-by: Wayen.Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/6a2be54b.ef98c1b2.3c3224.2ed8@mx.google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2ac37fca3052e9d73ac22ff857f4cccdb0f882c5 Author: Wayen.Yan Date: Fri Jun 12 07:09:13 2026 +0800 net: airoha: Fix register index for Tx-fwd counter configuration [ Upstream commit 1402ecccf5630a0b7fa4749d7d2e72abc3f3d73d ] In airoha_qdma_init_qos_stats(), the Tx-fwd counter configuration register uses the same index (i << 1) as the Tx-cpu counter, which overwrites the Tx-cpu configuration. The Tx-fwd counter value register correctly uses (i << 1) + 1, so the configuration register should use the same index. Fix the REG_CNTR_CFG index from (i << 1) to ((i << 1) + 1) so that the Tx-fwd counter is properly configured instead of clobbering the Tx-cpu counter config. Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support") Signed-off-by: Wayen.Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/6a2b40e7.4dd82583.3a5c46.e566@mx.google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit be55f99a0b088cb79549ae8c49fdbc63ecd7ef38 Author: Ratheesh Kannoth Date: Thu Jun 11 14:03:30 2026 +0530 octeontx2-af: fix NPC mailbox codes in mbox.h [ Upstream commit 925551c944a1de3058dc3fb55a517eea7749835d ] Several NPC mailbox command IDs in the 0x601x range were assigned out of order. Renumber and reorder the M() definitions so each opcode matches the stable contract expected by userspace tools and applications. Fixes: 4e527f1e5c15 ("octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon") Cc: Suman Ghosh Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260611083330.1652181-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6be4da4f5a16fa1335b2625232883955f116db41 Author: Ovidiu Panait Date: Wed Jun 10 08:52:38 2026 +0000 net: bcmgenet: Use weighted round-robin TX DMA arbitration [ Upstream commit fd615abd53110f0f815984e99e7cc51ca6b7d979 ] Under heavy network traffic, we observed sporadic TX queue timeouts on the Raspberry Pi 4. The timeouts can be reproduced by stress testing the TX path with multiple concurrent iperf UDP streams: iperf3 -c -u -b0 -P16 -t60 NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 2044 ms NETDEV WATCHDOG: CPU: 3: transmit queue 0 timed out 2004 ms Investigation showed that the timeouts are caused by the priority-based arbiter. Under heavy load the highest priority queue starves the lower priority ones, causing timeouts. The TX strict priority arbiter is not suitable for the default use case where all the traffic gets spread across all the TX queues. Therefore, to fix this, switch the TX DMA arbiter to Weighted Round-Robin, which services all queues, so they do not stall. The weights were chosen to follow the existing priority scheme: q0 gets the smallest weight, while q1-4 get the bulk of the TX bandwidth. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Ovidiu Panait Link: https://patch.msgid.link/20260610085238.56300-1-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0de5037dce5774ff574b449cb7c623913906ebf Author: Matthieu Buffet Date: Tue Jun 9 23:15:10 2026 +0200 landlock: Fix unmarked concurrent access to socket family [ Upstream commit 0ce4243509d1580349dd0d50624036d6b097e958 ] Socket family is read (twice) in a context where the socket is not locked, so another thread can setsockopt(IPV6_ADDRFORM) to write it concurrently. Add needed READ_ONCE() annotation. Use the proper macro to access __sk_common.skc_family like everywhere else. Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect") Signed-off-by: Matthieu Buffet Link: https://patch.msgid.link/20260609211511.85630-1-matthieu@buffet.re Link: https://patch.msgid.link/20260609211511.85630-2-matthieu@buffet.re [mic: Squash two patches, move variable to ease backport, fix comment formatting] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 467ae77921ada611a92c4654aee0c8293817bcc9 Author: Grzegorz Nitka Date: Sun Jun 7 20:30:39 2026 +0200 dpll: balance create/delete notifications in __dpll_pin_(un)register [ Upstream commit 1a2292101c0dc422466c673031de03d2e871adbe ] __dpll_pin_register() emits dpll_pin_create_ntf() internally, but __dpll_pin_unregister() left the matching delete to its callers. The counts then diverge on dpll_pin_on_pin_register() rollback and on dpll_pin_on_pin_unregister(), leaking stale notifications. Emit dpll_pin_delete_ntf() inside __dpll_pin_unregister() and drop the now-redundant call in dpll_pin_unregister(). Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260607183045.1213735-8-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c48e6581c433cdff280e0cc481e6c9480dc0a4b Author: Grzegorz Nitka Date: Sun Jun 7 20:30:38 2026 +0200 dpll: guard sync-pair removal on full pin unregister [ Upstream commit 0a5c720a7d57d2287d5566c4ad93ee26b7c06845 ] __dpll_pin_unregister() wiped the global sync-pair state on every (dpll, ops, priv, cookie) tuple removed from a pin. When a pin is registered multiple times and only one registration is being torn down, this dropped sync-pair pairings still in use by the surviving registrations. Move dpll_pin_ref_sync_pair_del() inside the xa_empty(&pin->dpll_refs) branch so it only runs when the last registration is gone, alongside clearing the DPLL_REGISTERED mark. Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260607183045.1213735-7-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc37a9a9495400aa9ce4f58aabeba676dfeef0d3 Author: Grzegorz Nitka Date: Sun Jun 7 20:30:37 2026 +0200 dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister() [ Upstream commit df0ba51ccf873e533669578104981109217d8201 ] dpll_pin_on_pin_register() emits a creation notification for every parent->dpll_refs entry, but dpll_pin_on_pin_unregister() emitted only one deletion notification outside the loop. When a pin is registered against multiple parent dplls, userspace sees N creates but a single delete and leaks per-dpll state. Move dpll_pin_delete_ntf() into the loop and call it before __dpll_pin_unregister() so the DPLL_REGISTERED mark is still set when dpll_pin_available() is consulted. Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260607183045.1213735-6-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ea6703cb3dc1309d399998cc1fdf5fe5048a401 Author: Grzegorz Nitka Date: Sun Jun 7 20:30:36 2026 +0200 dpll: send delete notification before unregister in on-pin rollback [ Upstream commit e83b403eb142be18d223fc599c0ac45519053671 ] The rollback path in dpll_pin_on_pin_register() called __dpll_pin_unregister() before dpll_pin_delete_ntf(). When the unregister dropped the pin's last DPLL reference it cleared the DPLL_REGISTERED mark in dpll_pin_xa, so the subsequent dpll_pin_event_send() failed dpll_pin_available() and aborted with -ENODEV. As a result userspace was never notified of the rollback deletion and remained out of sync with the kernel. Send the delete notification first, matching the order used by dpll_pin_unregister() and dpll_pin_on_pin_unregister(). Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Link: https://patch.msgid.link/20260607183045.1213735-5-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75a52d107203645341af365c10e7bf18df8d78d7 Author: Grzegorz Nitka Date: Sun Jun 7 20:30:35 2026 +0200 dpll: fix stale iteration in dpll_pin_on_pin_unregister() [ Upstream commit 32239d600236a986c8e6d16aa814d3d91066b244 ] Neither parent->dpll_refs nor pin->dpll_refs on its own is a correct iteration target at unregister time: - pin->dpll_refs includes DPLLs the child was registered against via a different parent or directly; blind unregister WARNs on the cookie miss in dpll_xa_ref_pin_del(). - parent->dpll_refs reflects the parent's current attachments, not those at child-register time. Another driver may have (un)reg'd the parent against additional DPLLs in the meantime, so we miss registrations that exist and visit DPLLs that have none. Walk pin->dpll_refs and use dpll_pin_registration_find() to filter to entries whose cookie is this parent. Symmetric with dpll_pin_on_pin_register(), correct under any subsequent change to parent->dpll_refs. Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Link: https://patch.msgid.link/20260607183045.1213735-4-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c1b25d85f4c9a0f85f3f8c39988ad266a3f3095 Author: Ruoyu Wang Date: Fri Jun 12 11:56:13 2026 +0800 net: wwan: t7xx: check skb_clone in control TX [ Upstream commit 05f789fa90d95d5771230e78453cedff2486039d ] t7xx_port_ctrl_tx() clones each skb fragment before passing it to the port transmit path. The clone is used immediately to set cloned->len, so an skb_clone() failure results in a NULL pointer dereference. Check the clone before using it. If previous fragments were already queued, preserve the driver's existing partial-write behavior by returning the number of bytes submitted so far. Fixes: 36bd28c1cb0d ("wwan: core: Support slicing in port TX flow of WWAN subsystem") Signed-off-by: Ruoyu Wang Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260612035613.1192486-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd791968b8418404cb8268bb9fdf13b56299c63e Author: Wentao Guan Date: Fri Jun 12 14:45:01 2026 +0800 net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show() [ Upstream commit 14a8bc41ce9edae42d56466063a7f2c84a16c45c ] WED_MON_AMSDU_ENG_CNT point to different entry by 'base+n*offset' mode, correct the wed amsdu entry number in wed_amsdu_show(). Fixes: 3f3de094e8342 ("net: ethernet: mtk_wed: debugfs: add WED 3.0 debugfs entries") Signed-off-by: Wentao Guan Link: https://patch.msgid.link/20260612064501.203058-1-guanwentao@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 10b83897a90c3518db832288e87efc4fd5502429 Author: Wayen.Yan Date: Fri Jun 12 17:37:00 2026 +0800 net: airoha: Fix error handling in airoha_ppe_flush_sram_entries() [ Upstream commit d7d81b00301398fcd38cf5b5869f0fdb674472ef ] In airoha_ppe_flush_sram_entries(), the outer "err" variable was never updated when the inner loop variable shadowed it, causing the function to always return 0 even when airoha_ppe_foe_commit_sram_entry() fails. Drop the outer "err" variable and return directly on error, propagating the error code from airoha_ppe_foe_commit_sram_entry() correctly. Fixes: 620d7b91aadb ("net: airoha: ppe: Flush PPE SRAM table during PPE setup") Link: https://lore.kernel.org/netdev/6a2b40e4.4dd82583.3a5c46.e52f@mx.google.com/ Signed-off-by: Wayen.Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/6a2bd37a.4034e349.1b41bb.1caf@mx.google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2477c523c6e69733d51101ae9bd2dfc0a054b13d Author: Ratheesh Kannoth Date: Wed Jun 10 07:53:44 2026 +0530 octeontx2-af: npc: Fix size of entry2cntr_map [ Upstream commit f9cd6fabe0e7c7f6fc30c6c192c7ed72aba37232 ] KASAN prints below splat. This is caused by allocating counter for reserved mcam entry for cpt 2nd pass entry. But mcam->entry2cntr_map is not allocated for reserved entries. BUG: KASAN: slab-out-of-bounds in npc_map_mcam_entry_and_cntr+0xb0/0x1a0 Write of size 2 at addr ffff0001033e7ffe by task kworker/0:1/14 CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.1.67 #1 Hardware name: Marvell CN106XX board (DT) Workqueue: events work_for_cpu_fn Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x88/0xb4 print_report+0x154/0x458 kasan_report+0xb8/0x194 __asan_store2+0x7c/0xa0 npc_map_mcam_entry_and_cntr+0xb0/0x1a0 rvu_mbox_handler_npc_mcam_write_entry+0x268/0x280 npc_install_flow+0x840/0xfe0 rvu_npc_install_cpt_pass2_entry+0x138/0x190 rvu_nix_init+0x148c/0x2880 rvu_probe+0x1800/0x30b0 local_pci_probe+0x78/0xe0 work_for_cpu_fn+0x30/0x50 process_one_work+0x4cc/0x97c worker_thread+0x360/0x630 kthread+0x1a0/0x1b0 ret_from_fork+0x10/0x20 Fixes: 55307fcb9258 ("octeontx2-af: Add mbox messages to install and delete MCAM rules") Cc: Subbaraya Sundeep Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260610022344.969774-1-rkannoth@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 442d232dbcd33578d3d57146c7ecc0d389a99ded Author: Xu Kuohai Date: Wed Jun 10 20:17:23 2026 +0000 bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno [ Upstream commit 4c71303c837449158815c521fcee4ec3b8721dbd ] When a cgroup BPF program exits with 0, bpf_prog_run_array_cg() sets the hook return value to -EPERM if it is not a valid errno. This is correct for errno-based hooks, which return 0 on success and negative errno on failure, but wrong for boolean and void LSM hooks. Boolean LSM hooks should only return true or false, and void LSM hooks have no return value at all. Fix it by skipping setting -EPERM for hooks not returning errno. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Signed-off-by: Xu Kuohai Link: https://lore.kernel.org/r/20260610201724.733943-2-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fe1b3f8d47ffc98fdebf38cacab522bf0a9227eb Author: Dragos Tatulea Date: Thu Jun 11 16:52:30 2026 +0300 net/mlx5: Check max_macs devlink param value against max capability [ Upstream commit d7b0413b35715d7b32cb12d4d424613eff85ed2b ] The max_macs devlink param is checked against the FW max value only at param register time (driver load) and inside the validate callback (devlink param set). The stored DRIVERINIT value persists across FW resets and devlink reloads without any further checks against the max. If the FW link type changes from Ethernet to IB and a FW reset happens, the MAX cap for log_max_current_uc_list will become zero, but the previously stored max_macs value remains and is unconditionally programmed into the HCA caps in handle_hca_cap(). FW will then return a syndrome during SET_HCA_CAP: mlx5_cmd_out_err:839:(pid 3831): SET_HCA_CAP(0x109) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x537801), err(-22) set_hca_cap:907:(pid 3831): handle_hca_cap failed This results in a failure to register the RDMA device. This patch skips programming log_max_current_uc_list when the MAX capability is 0 (in case of IB). Fixes: 8680a60fc1fc ("net/mlx5: Let user configure max_macs generic param") Signed-off-by: Dragos Tatulea Reviewed-by: Yael Chemla Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260611135230.534513-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b20679c00459a04f5cba5564926334e0cb83b09 Author: Sun Jian Date: Fri Jun 12 19:40:31 2026 +0800 bpf: Run generic devmap egress prog on private skb [ Upstream commit 6001896f00984d317fb75160ba05c4a885fbe2a0 ] Generic XDP devmap multi redirect uses skb_clone() for intermediate destinations and sends the last destination with the original skb. This can leave multiple destinations sharing the same packet data. This becomes visible after generic devmap egress-program support was added: a devmap egress program may mutate packet data, and another destination sharing the same data can observe that mutation. Native XDP broadcast redirect does not have this issue because xdpf_clone() copies the frame data for each destination. Generic XDP should provide the same per-destination isolation before running a devmap egress program. Fix this by making cloned skbs private before running the generic devmap egress program. Use skb_copy() instead of skb_unshare() so allocation failure does not consume the skb and the existing caller error paths keep their ownership semantics. Fixes: 2ea5eabaf04a ("bpf: devmap: Implement devmap prog execution for generic XDP") Suggested-by: Jiayuan Chen Suggested-by: Jakub Kicinski Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Sun Jian Link: https://lore.kernel.org/r/20260612114032.244616-2-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit dd3c3ed8f180a1536ef03743d7b9ffffd64175a4 Author: Victor Nogueira Date: Thu Jun 11 17:58:49 2026 -0300 net/sched: sch_dualpi2: Add missing module alias [ Upstream commit ee1ba0add3fbd5a28fa5423be373acd147f1e344 ] When a qdisc is added by name, the kernel tries to autoload its module via request_qdisc_module(), which calls: request_module(NET_SCH_ALIAS_PREFIX "%s", name); i.e. it asks modprobe to resolve the "net-sch-" alias (e.g. "net-sch-dualpi2") rather than the module's file name. Since dualpi2 was shipped without this alias, the autoload fails: tc qdisc add dev lo root handle 1: dualpi2 Error: Specified qdisc kind is unknown. Fix this by adding the missing alias so the qdisc is autoloaded on demand like the others. Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") Signed-off-by: Victor Nogueira Reviewed-by: Pedro Tammela Link: https://patch.msgid.link/20260611205849.3287640-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87a0daf4ddf993d9636ca7fd4163728ca60e1c25 Author: Zhi-Jun You Date: Thu Jun 11 23:00:51 2026 +0800 net: ethernet: mtk_wed: fix loading WO firmware for MT7986 [ Upstream commit 9192a18f6de2f5e3eb3813ecd2895ac0f5c008a9 ] MT7986 requires a different mask for second WO firmware. Without this, WO would timeout after loading FW. The correct mask was removed when adding WED for MT7988. Add it back and add a WED version check to fix it. This can be reproduced with a MT7986 + MT7916 board. Fixes: e2f64db13aa1 ("net: ethernet: mtk_wed: introduce WED support for MT7988") Signed-off-by: Zhi-Jun You Link: https://patch.msgid.link/20260611150051.586-1-hujy652@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ce2b00ff058ec4cafc9b447e1f0a6d6f49275d9 Author: Eric Dumazet Date: Thu Jun 11 15:27:37 2026 +0000 net: watchdog: fix refcount tracking races [ Upstream commit 8eed5519e496b7a07f441a0f579cb228a33189f7 ] Blamed commit converted the untracked dev_hold()/dev_put() calls in the watchdog code to use the tracked dev_hold_track()/dev_put_track() (which were later renamed/interfaced to netdev_hold() and netdev_put()). By introducing dev->watchdog_dev_tracker to store the reference tracking information without adding synchronization between netdev_watchdog_up() and dev_watchdog(), it enabled the race condition where this pointer could be overwritten or freed concurrently, leading to the list corruption crash syzbot reported: list_del corruption, ffff888114a18c00->next is NULL kernel BUG at lib/list_debug.c:52 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 91 Comm: kworker/u8:5 Not tainted syzkaller #0 PREEMPT(lazy) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 Workqueue: events_unbound linkwatch_event RIP: 0010:__list_del_entry_valid_or_report.cold+0x22/0x2a lib/list_debug.c:52 Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:246 [inline] list_move_tail include/linux/list.h:341 [inline] ref_tracker_free+0x1a7/0x6c0 lib/ref_tracker.c:329 netdev_tracker_free include/linux/netdevice.h:4491 [inline] netdev_put include/linux/netdevice.h:4508 [inline] netdev_put include/linux/netdevice.h:4504 [inline] netdev_watchdog_down net/sched/sch_generic.c:600 [inline] dev_deactivate_many+0x28c/0xfe0 net/sched/sch_generic.c:1363 dev_deactivate+0x109/0x1d0 net/sched/sch_generic.c:1397 linkwatch_do_dev net/core/link_watch.c:184 [inline] linkwatch_do_dev+0xd3/0x120 net/core/link_watch.c:166 __linkwatch_run_queue+0x3a5/0x810 net/core/link_watch.c:240 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:314 process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 [inline] worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 This patch has three coordinated parts: 1) Add dev->watchdog_lock and dev->watchdog_ref_held to serialize watchdog operations. 2) Remove netdev_watchdog_up() call from netif_carrier_on(): This ensures netdev_watchdog_up() is only called from process/BH context (via linkwatch workqueue dev_activate()), allowing us to use spin_lock_bh() for synchronization. 3) Synchronize watchdog up and watchdog timer: Protect netdev_watchdog_up() with tx_global_lock and watchdog_lock. Only allocate a new tracker in netdev_watchdog_up() if one is not already present. In dev_watchdog(), ensure we don't release the tracker if the timer was rescheduled either by dev_watchdog() itself or concurrently by netdev_watchdog_up(). Fixes: f12bf6f3f942 ("net: watchdog: add net device refcount tracker") Reported-by: syzbot+381d82bbf0253710b35d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a26b751.c25708ab.1b19ef.0013.GAE@google.com/T/#u Tested-by: syzbot+3479efbc2821cb2a79f2@syzkaller.appspotmail.com Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260611152737.2580480-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2d27bd4d4c7acc4312b854d67e22d958c689e72 Author: Aditya Garg Date: Mon Jun 8 03:13:41 2026 -0700 net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check [ Upstream commit f8fd56977eeea3d6939b1a9cd8bd36f1779b3ad0 ] mana_create_txq() has several error paths (after mana_alloc_queues() or mana_create_wq_obj() failure) where tx_qp[i].tx_object stays as the INVALID_MANA_HANDLE sentinel set at allocation. mana_destroy_txq() then unconditionally calls mana_destroy_wq_obj() with (u64)-1, which firmware rejects and logs an error. Mirror the RX-side pattern in mana_destroy_rxq() and skip the destroy when the handle is still INVALID_MANA_HANDLE. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg Reviewed-by: Dipayaan Roy Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260608101345.2267320-3-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 150590d9ab0dbeb0087193058363819d4c82a00f Author: Aditya Garg Date: Mon Jun 8 03:13:40 2026 -0700 net: mana: initialize gdma queue id to INVALID_QUEUE_ID [ Upstream commit 5985474e1cb4034680fac2145497a94b0860be50 ] mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg Reviewed-by: Dipayaan Roy Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260608101345.2267320-2-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 466f29477cae2bd1982a066d518a9b20c5a37924 Author: Victor Nogueira Date: Wed Jun 10 16:28:54 2026 -0300 net/sched: sch_dualpi2: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen [ Upstream commit 15cd0c93bf4f892d66bc7a93667e2357b5673365 ] Whenever dualpi2 drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though dualpi2 still has 1 packet on the queue and, thus, mistakenly deactivates the parent's class which leads to a null-ptr-deref: [ 101.427314][ T599] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] SMP KASAN NOPTI [ 101.427755][ T599] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 101.428048][ T599] CPU: 2 UID: 0 PID: 599 Comm: ping Not tainted 7.1.0-rc5-00284-gbce53c430ed7 #102 PREEMPT(full) [ 101.428400][ T599] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 101.428608][ T599] RIP: 0010:qfq_dequeue (net/sched/sch_qfq.c:1150) sch_qfq [ 101.428821][ T599] Code: 00 fc ff df 80 3c 02 00 0f 85 46 0c 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 2d 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b All code [ 101.429348][ T599] RSP: 0018:ffff8881110df4f0 EFLAGS: 00010216 [ 101.429541][ T599] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 101.429763][ T599] RDX: 0000000000000009 RSI: 00000024c0000000 RDI: ffff88811436c2b0 [ 101.429985][ T599] RBP: ffff88811436c000 R08: ffff88811436c280 R09: 1ffff11021277523 [ 101.430206][ T599] R10: 1ffff11021277526 R11: 1ffff11021277527 R12: 00000024c0000000 [ 101.430423][ T599] R13: ffff88811436c2b8 R14: 0000000000000048 R15: 0000000020000000 [ 101.430642][ T599] FS: 00007f61813e1c40(0000) GS:ffff8881691ef000(0000) knlGS:0000000000000000 [ 101.430913][ T599] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.431100][ T599] CR2: 00005651650850a8 CR3: 000000010ca0b000 CR4: 0000000000750ef0 [ 101.431320][ T599] PKRU: 55555554 [ 101.431433][ T599] Call Trace: [ 101.431544][ T599] [ 101.431628][ T599] __qdisc_run (net/sched/sch_generic.c:322 net/sched/sch_generic.c:427 net/sched/sch_generic.c:445) [ 101.431792][ T599] ? dev_qdisc_enqueue (./include/trace/events/qdisc.h:49 (discriminator 22) net/core/dev.c:4176 (discriminator 22)) [ 101.431941][ T599] __dev_queue_xmit (./include/net/pkt_sched.h:120 ./include/net/pkt_sched.h:117 net/core/dev.c:4292 net/core/dev.c:4831) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc") Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260610192855.3121513-4-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91e0a793a72374c20ab31a40ccec21373e82e973 Author: Victor Nogueira Date: Wed Jun 10 16:28:53 2026 -0300 net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen [ Upstream commit 52f1da34c9f4d5bdc1e8b44242da5c7ba8db85f3 ] Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. Fixes: 342debc12183 ("codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()") Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260610192855.3121513-3-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit af54df2f44d9605614bc7ed96640302a240a9a62 Author: Victor Nogueira Date: Wed Jun 10 16:28:52 2026 -0300 net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen [ Upstream commit 097f6fc7b1ae362dd7a9444b2572162fda73b284 ] Whenever fq_codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though fq_codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a recent report [1] and a wild memory access in qfq: [ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full) [ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 29.372620][ T360] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216 [ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000 [ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000 [ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024 [ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000 [ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578 [ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000 [ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0 [ 29.376103][ T360] PKRU: 55555554 [ 29.376258][ T360] Call Trace: [ 29.376401][ T360] ... [ 29.376885][ T360] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 29.377074][ T360] qdisc_reset (net/sched/sch_generic.c:1057) [ 29.377414][ T360] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 29.377600][ T360] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 29.378593][ T360] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. [1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Fixes: 342debc12183 ("codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()") Reported-by: Anirudh Gupta Closes: https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Tested-by: Anirudh Gupta Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260610192855.3121513-2-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 796dc63764d24bf01b68c02301ca9f9fafa68966 Author: Paolo Abeni Date: Thu Jun 11 18:36:48 2026 +0200 virtio_net: do not allow tunnel csum offload for non GSO packets [ Upstream commit 86c51f0f23136ea5ef5541f607287e07150cd23f ] Fiona reports broken connectivity for virtio net setup using UDP tunnel inside the guest and NIC with not UDP tunnel TSO support in the host. Currently the virtio_net driver exposes csum offload for UDP-tunneled, TCP non GSO packets. Such packet reach the host as CSUM_PARTIAL ones with the 'encapsulation' flag cleared, as the virtio specification do not support this specific kind of offload. HW NICs with UDP tunnel TSO support - and those drivers directly accessing skb->csum_start/csum_offset - are still capable of computing the needed csum correctly, but otherwise the packets reach the wire with bad csum on both the inner and outer transport header. Address the issue explicitly disabling csum offload for UDP tunneled, non GSO packets via the ndo_features_check op. Fixes: 56a06bd40fab ("virtio_net: enable gso over UDP tunnel support.") Reported-by: Fiona Ebner Closes: https://bugzilla.proxmox.com/show_bug.cgi?id=7627 Tested-by: Fiona Ebner Tested-by: Gabriel Goller Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Reviewed-by: Gabriel Goller Tested-by: Gabriel Goller Link: https://patch.msgid.link/6c3b6c47fb05c100f384630dc48f3975cf37b67a.1781195144.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8874dafc9099bc49c2e5ebba030f85d276421f92 Author: Sechang Lim Date: Thu Jun 11 09:29:18 2026 +0000 tcp: clear sock_ops cb flags before force-closing a child socket [ Upstream commit 990348e5bb457697c2f1f7f7b65154a3334d9d2b ] A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too. Suggested-by: Jiayuan Chen Fixes: d44874910a26 ("bpf: Add BPF_SOCK_OPS_STATE_CB") Signed-off-by: Sechang Lim Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260611092923.1895982-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb72b1c6755631c74b7e0878ee55bb81c06776c0 Author: Joe Damato Date: Tue Jun 9 13:44:58 2026 -0700 bnxt: fix head underflow on XDP head-grow [ Upstream commit e26657fe3b85c068b01f42bb0c602f242d643ba9 ] The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue. Fixes: f6974b4c2d8e ("bnxt_en: Fix page pool logic for page size >= 64K") Signed-off-by: Joe Damato Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260609204458.2237787-2-joe@dama.to Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4dafc411948469277b276724c3b2b4408c02c04c Author: Chuck Lever Date: Tue Jun 9 10:18:31 2026 -0400 handshake: Require admin permission for DONE command [ Upstream commit 81246a65303d9635266b1334490142caaf86a11f ] ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENL_ADMIN_PERM; DONE has no privilege check at all. The fd-lookup in handshake_nl_done_doit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKE_A_DONE_STATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Reviewed-by: Jeff Layton Reviewed-by: Hannes Reinecke Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20260609141831.90694-1-cel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 14357ba006e1586e4b4e809c074b21baf0aa4c4b Author: Lucas Tsai Date: Tue Jun 9 19:44:03 2026 +0800 power: supply: core: fix supplied_from allocations [ Upstream commit ba61aed9a34671222d1149acfc2f0179a9ce7e80 ] If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in __power_supply_populate_supplied_from will overrun supplied_from array. Fixes: f6e0b081fb30 ("power_supply: Populate supplied_from hierarchy from the device tree") Signed-off-by: Lucas Tsai Link: https://patch.msgid.link/20260609114403.3896073-1-lucas_tsai@richtek.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c4c7aeb3e5f4243519b474f8c73d4fcffdb2d3a6 Author: Dan Williams Date: Tue May 19 14:01:56 2026 -0700 cxl/memdev: Pin parents for entire memdev lifetime [ Upstream commit bd3a6ff4b84e0fc3fca8556d338270603df13f2e ] In order to be able to manage the driver that uses a memdev attach mechanism the parent needs to stick around for the device_release_driver(cxlmd->dev.parent) event. Fixes: 29317f8dc6ed ("cxl/mem: Introduce cxl_memdev_attach for CXL-dependent operation") Signed-off-by: Dan Williams Reviewed-by: Alejandro Lucero Tested-by: ALejandro Lucero Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260519210158.1499795-4-djbw@kernel.org Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit be44c1c04f85d7b7ac1c597a30b443bbd346acbd Author: Dan Williams Date: Tue May 19 14:01:55 2026 -0700 cxl/region: Resolve region deletion races [ Upstream commit 4dd86ca99ffcc413cbf79063fd9956ef54e0ca91 ] Sungwoo noticed that the sysfs trigger to delete a region may try to delete a region multiple times. It also has no exclusion relative to the kernel releasing the region via CXL root device teardown. Instead of installing new cxl root devres actions per region, use the existing root decoder unregistration event to remove all remaining regions. An xarray of regions replaces a devres list of regions. This handles 3 separate issues with the old approach: 1/ sysfs users racing to delete the same region: no longer possible now that the regions_lock is held over the lookup and deletion. 2/ multiple actions triggering deletion of the same region: solved by erasing regions while holding @regions_lock, and only proceeding on successful erasure. 3/ userspace racing devres_release_all() to trigger the devres not found warning: solved by sysfs unregistration not requiring a release action Fixes: 779dd20cfb56 ("cxl/region: Add region creation support") Reported-by: Sungwoo Kim Closes: http://lore.kernel.org/20260427032010.916681-2-iam@sung-woo.kim Signed-off-by: Dan Williams Reviewed-by: Alejandro Lucero Tested-by: ALejandro Lucero Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260519210158.1499795-3-djbw@kernel.org Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit b0b6a9c65cb72c901fdcc6ae83d7afd70cdca1b8 Author: Dan Williams Date: Tue May 19 14:01:54 2026 -0700 cxl/region: Block region delete during region creation [ Upstream commit d91feb88692e81b00cd22f0125cfcd04970b4a0b ] Expand the range lock, rename it "regions_lock", to disable region deletion in the critical period between construct_region() and attach_target(), as well as the period between device_add() and registering the remove actions. Otherwise, userspace can confuse the kernel. It can violate the assumption the region stays registered through the completion of cxl_add_to_region(). It can violate the assumption that devm_add_action_or_reset() is working with a live 'struct cxl_region'. It is ok for the region to disappear outside of those windows as that mirrors device hotplug flows where the proper locks are held. Fixes: a32320b71f08 ("cxl/region: Add region autodiscovery") Signed-off-by: Dan Williams Reviewed-by: Alejandro Lucero Tested-by: ALejandro Lucero Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260519210158.1499795-2-djbw@kernel.org Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 2e8e11cd32243a2cefe13cd8be59c7cda995b37a Author: Guangshuo Li Date: Thu Jun 4 20:55:20 2026 +0800 ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO [ Upstream commit 69b4141b428bcf2cf7a863950c0d6e5c5ae89ac1 ] The PLL lock failure path in adau1372_set_power() unwinds by putting the regmap back in cache-only mode, asserting the optional power-down GPIO and disabling mclk. adau1372_enable_pll() enables CLK_CTRL.PLL_EN before polling the PLL lock bit. If the lock fails on a board without a power-down GPIO, the error path disables mclk and returns an error, but leaves PLL_EN set in the hardware register. The normal power-off path already handles the no-GPIO case by explicitly clearing PLL_EN. Mirror that cleanup in the PLL lock failure path and clear PLL_EN while the regmap is still live, before switching it back to cache-only mode. Fixes: bfe6a264effc ("ASoC: adau1372: Fix clock leak on PLL lock failure") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260604125520.1428905-1-lgs201920130244@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 93299544227948cab8b2700aa7198075278f677b Author: David Matlack Date: Thu Jun 11 21:39:45 2026 +0000 vfio: selftests: Ensure libvfio output dirs are always created [ Upstream commit 785562e31dbcd85ca583cf58c446e63aa8a5af08 ] Add an explicit dependency between the output object files and the output directories that need to be created to hold those files. This ensures that the output directories are always created. Creating the output directories at parse time (current behavior) doesn't support the scenario where someone does "make clean all". The directories will be created during parsing, deleted during "clean" and then not available for the "all" target. Use an order-only prerequisite for the output directories, rather than a normal prerequisite, to avoid unnecessary recompilations. Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests") Reported-by: Sashiko Closes: https://lore.kernel.org/kvm/20260610010314.DB8861F00893@smtp.kernel.org/ Signed-off-by: David Matlack Link: https://lore.kernel.org/r/20260611213945.3714421-1-dmatlack@google.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 6fde3fcdfec438ba0df26e25a8ac7c3707211799 Author: Li Ming Date: Sat Jun 6 15:51:01 2026 +0800 cxl/region: Fill first free targets[] slot during auto-discovery [ Upstream commit aa8a76711c15041ec1e42c3a74c15c2df0bd31f6 ] Any invalid endpoint decoder pointer in the target array of an active region is not allowed by cxl driver. This means cxl driver always assumes the first p->nr_targets entries of the target array in an auto-assembly region are valid. However, there are scenarios that could leave NULL endpoint decoder pointer holes in the target array. 1. When cxl_cancel_auto_attach() removes an endpoint decoder from a target array, the target slot is set to NULL. If the removed endpoint decoder is not the last element in the target array, the target array will contain a NULL hole. 2. When a auto-assembly region removes an assigned endpoint decoder, if the removed endpoint decoder is not the last element in the target array, always remains a NULL hole in the target array. When a NULL pointer hole exists in a region's target array, it introduces two potential problems: 1. Access an endpoint decoder via a NULL pointer. it always trigger calltrace like that. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KASAN PTI RIP: 0010:cxl_calc_interleave_pos+0x26/0x810 [cxl_core] Call Trace: cxl_region_attach+0xc50/0x2140 [cxl_core] cxl_add_to_region+0x321/0x2330 [cxl_core] discover_region+0x92/0x150 [cxl_port] device_for_each_child+0xf3/0x170 cxl_port_probe+0x150/0x200 [cxl_port] cxl_bus_probe+0x4f/0xa0 [cxl_core] really_probe+0x1c8/0x960 __driver_probe_device+0x323/0x450 driver_probe_device+0x45/0x120 __device_attach_driver+0x15d/0x280 bus_for_each_drv+0x10f/0x190 2. Not having enough valid endpoint decoders attached to an auto-assembly region. if an auto-assembly region is created with lock flag or assigned endpoint decoder with lock flag, which means assigned endpoint decoder will not be reset during detaching, they could re-attach to the auto-assembly region again. But cxl region driver relies on p->nr_targets to verify whether the required number of endpoint decoders has been attached, and NULL endpoint decoder pointers are still counted in that case. To fix above issues, adjust cxl_region_attach_auto() logic to find the first free target slot for endpoint decoder attachment, this ensures NULL holes in the target array are filled, rather than adding new endpoint decoders at the tail of the target array. Fixes: 87805c32e6ad ("cxl/region: Fix use-after-free from auto assembly failure") Fixes: 2230c4bdc412 ("cxl: Add handling of locked CXL decoder") Suggested-by: Alison Schofield Signed-off-by: Li Ming Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260606-fix_two_issues_introduced_by_cxl_cancel_auto_attach-v1-2-5d94ca06c4e4@zohomail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 44b2397eb67b7f728640989a22d062e41f94ab64 Author: Li Ming Date: Sat Jun 6 15:51:00 2026 +0800 cxl/region: Fix out-of-bounds access in cxl_cancel_auto_attach() [ Upstream commit cbda6a2c2bec2a5fb30a2ce85baeab15b5fc7db3 ] In cxl_cancel_auto_attach(), it assumes cxled->pos is a valid index for accessing p->targets[]. However, cxled->pos can be set to negative errno in cxl_region_sort_targets() if cxl_calc_interleave_pos() fails. This causes the driver to use a negative index to access p->targets[], resulting in out-of-bounds access. Fix it by walking p->targets[] instead of using cxled->pos directly. Fixes: 87805c32e6ad ("cxl/region: Fix use-after-free from auto assembly failure") Signed-off-by: Li Ming Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260606-fix_two_issues_introduced_by_cxl_cancel_auto_attach-v1-1-5d94ca06c4e4@zohomail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit d1a993c8ce3f2c978aeea16180e977cf54ca5588 Author: Chia-Lin Kao (AceLan) Date: Wed Jun 10 12:17:53 2026 +0800 ASoC: sdw_utils: fix missing component_name for cs42l43 part_id 0x2A3B [ Upstream commit c429fbea6174a7dd40c4215288589a50e8a33ff6 ] commit 87a3f5c8ac20 ("ASoC: sdw_utils: cs42l43: allow spk component names to be combined") moved spk:cs42l43-spk generation from rtd_init() into the asoc_sdw_rtd_init() generic path by adding component_name to codec_info_list entries. However, only the 0x4243 cs42l43 entry was updated; the 0x2A3B entry (vendor_id 0x01fa, Cirrus Logic cs42l43 with sidecar bridge) was missed. Without component_name on the 0x2A3B dp6 DAI, asoc_sdw_rtd_init() never accumulates spk_components and never appends 'spk:cs42l43-spk' (or its sidecar alias 'spk:cs35l56-bridge') to card->components. The sof-soundwire UCM regex ' spk:([a-z0-9]+...)' then fails to match, causing WirePlumber to mark all HiFi profiles as unavailable=no and fall back to the Off profile — resulting in Dummy Output in GNOME. The existing sidecar redirect in asoc_sdw_rtd_init() already handles the SOC_SDW_SIDECAR_AMPS case: when component_name is 'cs42l43-spk' and sidecar amps are active, it substitutes 'cs35l56-bridge' into card->components, which matches the existing cs35l56-bridge.conf UCM file. Fixes: 87a3f5c8ac20 ("ASoC: sdw_utils: cs42l43: allow spk component names to be combined") Signed-off-by: Chia-Lin Kao (AceLan) Link: https://patch.msgid.link/20260610041753.1151088-1-acelan.kao@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 119f943c67a7e9bf1187089f349ec547cd9713ed Author: Nicolin Chen Date: Wed Jun 3 14:26:55 2026 -0700 iommu: Avoid copying the user array twice in the full-array copy helper [ Upstream commit e28bee5b445178390d63f7a93a5a219063c6434e ] iommu_copy_struct_from_full_user_array() copies a whole user array into a kernel buffer. In the common case, where user entry_len equals destination entry size, it takes a fast path and copies the whole array with a single copy_from_user(). That fast path does not return, so it falls through into the item-by-item copy_struct_from_user() loop and copies every entry a second time. For an equal entry_len that loop is just a copy_from_user() of the same bytes, so the whole array is copied twice for no benefit. Return right after the bulk copy. The per-item loop then runs only on the slow path, where entry_len differs and each entry needs size adaption. Fixes: 4f2e59ccb698 ("iommu: Add iommu_copy_struct_from_full_user_array helper") Link: https://patch.msgid.link/r/6c9eca4ff584cb977661e97799ac6fe934e7f51c.1780521606.git.nicolinc@nvidia.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d1944b71c18e7494756bff1a6f80c25be99eaecb Author: Lars Pöschel Date: Fri Jun 12 12:52:44 2026 +0200 spi: xilinx: use FIFO occupancy register to determine buffer size [ Upstream commit 47f3b5365536e8c38f264824ab15fdb74454e066 ] The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); if (!(sr & XSPI_SR_RX_EMPTY_MASK)) { xilinx_spi_rx(xspi); rx_words--; } It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size. Fixes: 4c9a761402d7 ("spi/xilinx: Simplify spi_fill_tx_fifo") Signed-off-by: Lars Pöschel Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260612105244.9076-1-lars.poeschel.linux@edag.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3f6340faca9efb68f4df4f4da4bd7a30615bab0a Author: Alex Mastro Date: Wed Jun 10 13:44:41 2026 -0700 iommufd: Clarify IOAS_MAP_FILE dma-buf support [ Upstream commit 298ab7e6f1637cec44163f52e84e2030ec16ed9d ] IOMMU_IOAS_MAP_FILE is documented as mapping a memfd, but the implementation first tries to resolve the fd as a dma-buf and has a special path for supported dma-buf exporters. In particular, VFIO PCI dma-bufs exported through VFIO_DEVICE_FEATURE_DMA_BUF can be mapped when they describe a single DMA range. Update the UAPI comment so userspace understands that certain kinds of dma-buf are supported in addition to memfd. Fixes: 44ebaa1744fd ("iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE") Link: https://patch.msgid.link/r/20260610-tmp-v1-1-b8ccbf557391@fb.com Signed-off-by: Alex Mastro Assisted-by: Codex:gpt-5.5-high Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8646f00ce021e49f4f05bc1d4060a0c27b25d0e1 Author: Li RongQing Date: Sat May 30 07:28:52 2026 -0400 iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path [ Upstream commit db50fb87015b955a5a0c155293b2dd40d63a3b9e ] In iommu_dma_map_sg(), when handling PCI P2PDMA cases, the DMA length of the current scatterlist segment `s` is incorrectly assigned from the head entry `sg->length` instead of the current entry `s->length`. This typo causes all P2PDMA segments in the scatterlist to inherit the length of the first segment, leading to corrupted DMA lengths for multi- segment scatterlists. Fix this by using `s->length` instead of `sg->length`. Fixes: a25e7962db ("PCI/P2PDMA: Refactor the p2pdma mapping helpers") Signed-off-by: Li RongQing Reviewed-by: Logan Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 0527a56cb327021cb73167cfddf0e49efa043500 Author: HanQuan Date: Fri Jun 12 10:32:22 2026 +0000 ALSA: seq: Fix kernel heap address leak in bounce_error_event() [ Upstream commit efc86691e4d8083d9e380ea95042c2cf679f65fd ] The comment above bounce_error_event() documents that user clients should receive SNDRV_SEQ_EVENT_BOUNCE with the original event embedded as variable-length data, while kernel clients should receive SNDRV_SEQ_EVENT_KERNEL_ERROR with a quoted kernel pointer. However, the implementation unconditionally uses SNDRV_SEQ_EVENT_KERNEL_ERROR with data.quote.event set to the raw struct snd_seq_event pointer for all clients. When a bounce error event is delivered to a USER_CLIENT via snd_seq_read(), the kernel heap address in data.quote.event is exposed to userspace through copy_to_user() in the fixed-length branch. This is a distinct leak path from the one addressed by commit 705dd6dcbc0e ("ALSA: seq: Clear variable event pointer on read"), which sanitizes data.ext.ptr in the variable-length branch of snd_seq_read(). The bounce_error_event() leak uses fixed-length events that take the else branch where no sanitization occurs. Differentiate the bounce event by client type. For USER_CLIENT, send SNDRV_SEQ_EVENT_BOUNCE with SNDRV_SEQ_EVENT_LENGTH_VARIABLE and data.ext pointing to the original event. The variable-length path in snd_seq_event_dup() copies the event data into chained cells, and snd_seq_expand_var_event() copies only the content -- never the pointer -- to userspace. For KERNEL_CLIENT, keep the existing SNDRV_SEQ_EVENT_KERNEL_ERROR behavior with the quoted pointer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: HanQuan Link: https://patch.msgid.link/20260612103222.2528305-1-eilaimemedsnaimel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 89345f1cf007a6ea626cca1488c4d60c49631322 Author: Cássio Gabriel Date: Thu Jun 11 10:57:22 2026 -0300 ALSA: usb-audio: qcom: Guard sideband endpoint removal [ Upstream commit 2773023abb381e36ce02d364022d901f6f7a416d ] qmi_stop_session() conditionally looks up the cached data and sync endpoints, but removes each endpoint unconditionally. The data endpoint is always present for an active offload stream, while the sync endpoint is optional. When no sync endpoint exists, ep still refers to the data endpoint and the code attempts to remove that endpoint a second time. The current sideband implementation rejects the duplicate removal, but the teardown path should not pass an unrelated endpoint for an absent sync endpoint. Only look up and remove an endpoint when its cached pipe exists, check the lookup result, and clear the cached pipe after handling it. This matches the normal stream-disable path. Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260611-alsa-usb-qcom-guard-sideband-endpoint-removal-v1-1-00e73787c156@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f92b8ba180658cfd1351b98d5e5ae4d144a2daac Author: Herbert Xu Date: Thu Jun 4 12:30:54 2026 +0800 crypto: rng - Free default RNG on module exit [ Upstream commit 606ba888b98e0d26a2c4e5c8dc0542e3ad8f0f3a ] When the rng module is removed the default RNG will be leaked. Call crypto_del_default_rng to free it if possible. Fixes: 7cecadb7cca8 ("crypto: rng - Do not free default RNG when it becomes unused") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d319b83b97b3585550d9ae592dfa78c755b6129e Author: Felix Gu Date: Tue Jun 2 22:55:35 2026 +0800 crypto: cavium/cpt - fix DMA cleanup using wrong loop index [ Upstream commit 9dbf173bd32d5f81b005008b682bfb50aa093455 ] The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one. Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Felix Gu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit acff30cfc0d72465b51b0bfdf019f1cb54e15314 Author: Felix Gu Date: Tue Jun 2 22:38:26 2026 +0800 crypto: marvell/octeontx - fix DMA cleanup using wrong loop index [ Upstream commit 7891c64c0520519782470ba29bac8a5761e295d8 ] The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one. Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Felix Gu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d37344fc7729aa24e4576245db81803c8c190fa9 Author: Dave Jiang Date: Thu Jun 11 16:03:05 2026 -0700 cxl/test: Add check after kzalloc() memory in alloc_mock_res() [ Upstream commit dfe28c8592538152e9611341dae6f7be1735b3f1 ] alloc_mock_res() calls kzalloc() without checking the return value. Add scope based resource management to deal with the allocated memory cleanly. Reported-by: sashiko-bot Fixes: 67dcdd4d3b83 ("tools/testing/cxl: Introduce a mocked-up CXL port hierarchy") Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260611230305.197390-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit a79b884de8fb7fd6019d2c3d8cd23695a17d898a Author: Dave Jiang Date: Thu Jun 11 16:03:55 2026 -0700 cxl/test: Unregister cxl_acpi in cxl_test_init() error path [ Upstream commit 50cc34be04a0ea7522b739c9c7a71367cfbc489c ] In cxl_test_init(), Once cxl_mock_platform_device_add() succeeds, all error paths after needs to call platform_device_unregister() instead of platform_device_put() to clean up. Fixes: 67dcdd4d3b83 ("tools/testing/cxl: Introduce a mocked-up CXL port hierarchy") Reported-by: sashiko-bot Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260611230355.198912-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 973bf0ed896b9898668dbadb82ed849d7d573010 Author: Michael Bommarito Date: Wed Jun 10 08:40:03 2026 -0400 tipc: reject inverted service ranges from peer bindings [ Upstream commit 2afb648f7b99216c687db1f89739c995e1144153 ] tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper. Fixes: 37922ea4a310 ("tipc: permit overlapping service ranges in name table") Signed-off-by: Michael Bommarito Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260610124003.3831170-4-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e2c956745777e6ffdee7f30da5935741c03ee1e Author: Michael Bommarito Date: Wed Jun 10 08:40:02 2026 -0400 tipc: prevent snt_unacked underflow on CONN_ACK [ Upstream commit ab3e10b44ba5411779aac7afd2477917dd77750f ] tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: tsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack. Fixes: 10724cc7bb78 ("tipc: redesign connection-level flow control") Signed-off-by: Michael Bommarito Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260610124003.3831170-3-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 56f0a2e0a1d004e025cd031c3a801ab73959269f Author: Michael Bommarito Date: Wed Jun 10 08:40:01 2026 -0400 tipc: require net admin for TIPCv2 netlink mutators [ Upstream commit 86b0c540e2ea397cde021eecd24145f7c16a3d4e ] TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM. Fixes: 0655f6a8635b ("tipc: add bearer disable/enable to new netlink api") Link: https://lore.kernel.org/all/20260604163102.2658553-1-dominik.czarnota@trailofbits.com/ Signed-off-by: Michael Bommarito Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260610124003.3831170-2-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a49bbae676fef1ffe548971e6229ae2adeb9d10 Author: Victor Nogueira Date: Wed Jun 10 10:28:24 2026 -0300 net/sched: sch_hfsc: Don't make class passive twice [ Upstream commit 90b662ea25f5e83bb3b8ccec5b93ced810b92fb8 ] update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once. Fixes: 51eb3b65544c ("sch_hfsc: make hfsc_qlen_notify() idempotent") Reported-by: Anirudh Gupta Closes: https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Tested-by: Anirudh Gupta Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260610132824.3027549-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03f4c6ed3cffbfce0b85a3a0193d08a46692a9f8 Author: Daniel Borkmann Date: Tue Jun 9 23:22:40 2026 +0200 net: Stop leased rxq before uninstalling its memory provider [ Upstream commit 37314c9dbe95b4d924c7b61aaf563cec4f4e4133 ] netif_rxq_cleanup_unlease() tears down the memory provider that was installed on a physical RX queue through a netkit queue lease. It currently revokes the provider's DMA mappings before stopping the physical queue: __netif_mp_uninstall_rxq(virt_rxq, p); /* DMA unmap */ __netif_mp_close_rxq(phys_rxq->dev, rxq_idx, p); /* queue stop */ This inverts the ordering used by the regular teardown paths (normal device unregister and the io_uring zcrx close path), which stop the queue before revoking the provider's mappings. With the physical queue still live, its NAPI can keep consuming net_iov entries from the page_pool alloc cache after the __netif_mp_uninstall_rxq() has already cleared their dma_addr, opening a window for the device to DMA to a stale or zero address. Fix it by swapping the two calls so the queue is stopped (and its NAPI quiesced) before the provider is uninstalled. No functional regression was observed across repeated runs of the nk_qlease.py HW selftest, which exercises the lease teardown path; this was tested against fbnic QEMU emulation. Fixes: 5602ad61ebee ("net: Proxy netif_mp_{open,close}_rxq for leased queues") Reported-by: Ahmed Abdelmoemen Signed-off-by: Daniel Borkmann Cc: David Wei Reviewed-by: Bobby Eshleman Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260609212240.677889-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 67e4b283de36d9eebf95acdea5d6674b6ef4b2f4 Author: Samuel Moelius Date: Tue Jun 9 23:22:45 2026 +0000 net: pfcp: allocate per-cpu tstats for PFCP netdevs [ Upstream commit 24041543da8cd84eb5d8ae738c534372fff54820 ] PFCP uses dev_get_tstats64() as its ndo_get_stats64 callback, but pfcp_link_setup() does not request NETDEV_PCPU_STAT_TSTATS. The net core therefore leaves dev->tstats NULL for PFCP devices. Creating a PFCP rtnetlink device can immediately ask the new netdev for stats while building the RTM_NEWLINK notification. That reaches dev_get_tstats64() and dereferences the NULL dev->tstats pointer. Set pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS during PFCP link setup so the net core allocates the storage expected by dev_get_tstats64(). Fixes: 76c8764ef36a ("pfcp: add PFCP module") Signed-off-by: Samuel Moelius Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260609232244.1602027.c569f6c530f6.pfcp-missing-tstats-link-create-oops@trailofbits.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c674b20c9cdb54f8a46c88b4d00cadf82b8f0c0 Author: Xin Long Date: Tue Jun 9 18:14:28 2026 -0400 sctp: validate embedded address parameter length [ Upstream commit e9361d0ca55c4af12aac09e2572852fa91046229 ] sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: sashiko Signed-off-by: Xin Long Link: https://patch.msgid.link/7838b86b69f52add28808fb59034c8f992e97b2d.1781043268.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 865643640b5b5c4579b32d7a55ac9ad648362eaa Author: Xiang Mei Date: Mon Jun 8 23:51:16 2026 -0700 bridge: cfm: reject invalid CCM interval at configuration time [ Upstream commit f3e02edd8322b31b8e6517faa6ba053bf29d1e26 ] ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc). Fixes: 2be665c3940d ("bridge: cfm: Netlink SET configuration Interface.") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Acked-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260609065116.2818837-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3af0bc1bd9039e2e50abf3e2d7fee411f38bce4e Author: Kuniyuki Iwashima Date: Wed Jun 10 06:17:19 2026 +0000 net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). [ Upstream commit 2821e85c058f81c9948a2fb1a634f7b47457d51c ] rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump(). Fixes: 5d7bfd141924 ("ipv4: fib_rules: Dump FIB rules when registering FIB notifier") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260610061744.2030996-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 676482da8d938ea72c26da0fc86af2d2ec238ab2 Author: Kuniyuki Iwashima Date: Wed Jun 10 06:17:18 2026 +0000 ipv4: fib: Don't dump dying fib_info in fib_leaf_notify(). [ Upstream commit 06b693d2eb6651a63ad85bad8673de3b7d4edd6d ] syzbot reported use-after-free in nsim_fib4_prepare_event(). [0] The problem is that the following functions call fib_info_hold() / refcount_inc() while dumping fib_info under RCU, which is unsafe. * mlxsw_sp_router_fib4_event() * rocker_router_fib_event() * nsim_fib4_prepare_event() refcount_inc_not_zero() must be used, but it would be too late there. Let's guarantee the lifetime of fib_info in fib_leaf_notify(). Note that IPv6 does not need the corresponding change since fib6_table_dump() holds fib6_table.tb6_lock. [0]: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420 Modules linked in: CPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Workqueue: netns cleanup_net RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25 Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a <67> 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f RSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293 RAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0 RBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000 R13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000 FS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] fib_info_hold include/net/ip_fib.h:629 [inline] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25 call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline] fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline] fib_table_notify net/ipv4/fib_trie.c:2194 [inline] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217 fib_net_dump net/core/fib_notifier.c:70 [inline] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c:475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558 ops_pre_exit_list net/core/net_namespace.c:161 [inline] ops_undo_list+0x187/0x940 net/core/net_namespace.c:234 cleanup_net+0x56e/0x800 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: 0ae3eb7b4611 ("netdevsim: fib: Perform the route programming in a non-atomic context") Fixes: c3852ef7f2f8 ("ipv4: fib: Replay events when registering FIB notifier") Reported-by: syzbot+cb2aa2390ac024e25f5c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a290011.39669fcc.33b062.00b1.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260610061744.2030996-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6151159618198675e01c391676e579738286c135 Author: Jamal Hadi Salim Date: Wed Jun 10 06:18:39 2026 -0400 net/sched: cls_flow: Dont expose folded kernel pointers [ Upstream commit f294fc71c4a0fa4964f6428a1b4e7929c1d83125 ] The flow classifier falls back to addr_fold() for fields that are missing from packet headers. In map mode, userspace controls mask, xor, rshift, addend and divisor, and can observe the resulting classid through class statistics. This allows a tc classifier in a user/network namespace to recover the 32-bit folded value of skb->sk, skb_dst() or skb_nfct(). Align with standard kernel practices for pointer hashing and replace the XOR folding with a keyed siphash (which is cryptographically secure) Fixes: e5dfb815181f ("[NET_SCHED]: Add flow classifier") Reported-by: Kyle Zeng Tested-by: Kyle Zeng Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260610101839.14135-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5560427efb1b3fd0a3d45cf1dc477e3b9e96f702 Author: George Moussalem Date: Mon Jun 8 11:22:08 2026 +0400 net: dsa: qca8k: fix led devicename when using external mdio bus [ Upstream commit 0b7b378ce6cafbb948786cb6f17f406d94016c8c ] The qca8k dsa switch can use either an external or internal mdio bus. This depends on whether the mdio node is defined under the switch node itself. Upon registering the internal mdio bus, the internal_mdio_bus of the dsa switch is assigned to this bus. When an external mdio bus is used, the driver still uses the internal_mdio_bus id which is used to create the device names of the leds. This leads to the leds being prefixed with '(efault)' as the internal_mii_bus is null. So let's fix this by adding a null check and use the devicename of the external bus instead when an external bus is configured. Fixes: 1e264f9d2918 ("net: dsa: qca8k: add LEDs basic support") Signed-off-by: George Moussalem Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260608-qca8k-leds-fix-v3-1-a915bb2f37ae@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba37b62ed0a443b8e23f53a7477e7f2537fd34c7 Author: Cássio Gabriel Date: Thu Jun 4 00:10:58 2026 -0300 ASoC: topology: Check PCM and DAI name strings before use [ Upstream commit b7e44d1986d6671342c19b82192189ca5db5dab7 ] Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings. Fixes: 64527e8a3529 ("ASoC: topology: Add FE DAIs dynamically") Fixes: acfc7d46cddc ("ASoC: topology: Add FE DAI links dynamically") Fixes: 0038be9a84dc ("ASoC: topology: Add support for configuring existing BE DAIs") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260604-asoc-topology-check-pcm-dai-names-v1-1-e1b0f6f7c2ce@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 226d93b65f4f99b35fb7a03bdb24acb577364ebc Author: HyeongJun An Date: Tue Jun 9 21:43:16 2026 +0900 ASoC: tegra: tegra210_ahub: Validate written enum value [ Upstream commit 1d8aabb413b5638670dfd1162169edc0ba276a2e ] tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access. Fixes: 16e1bcc2caf4 ("ASoC: tegra: Add Tegra210 based AHUB driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260609124317.38046-5-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5b7a23c1ed04e794ef3b31e452ef5c93e1e34b4a Author: HyeongJun An Date: Tue Jun 9 21:43:15 2026 +0900 ASoC: fsl: fsl_audmix: Validate written enum values [ Upstream commit 3cd17e4e2871114d5579fa7bc8da66faf7fc1930 ] fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them. Fixes: be1df61cf06e ("ASoC: fsl: Add Audio Mixer CPU DAI driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260609124317.38046-4-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0965892cc486ca554d72eeb62d85ccf8d0137a5a Author: HyeongJun An Date: Tue Jun 9 21:43:14 2026 +0900 ASoC: meson: aiu: Validate written enum values [ Upstream commit d65adf85477247be04ac86886f8edfaa047b5d4a ] The AIU HDMI and internal codec mux put callbacks use the written enum value with snd_soc_enum_item_to_val() before checking whether the value is valid for the enumeration. Reject out-of-range values before converting the enum item, matching the validation already done by the G12A HDMI and internal codec mux controls. Fixes: b82b734c0e9a ("ASoC: meson: aiu: add hdmi codec control support") Fixes: 65816025d461 ("ASoC: meson: aiu: add internal dac codec control support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260609124317.38046-3-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d8961b5c7889b6ecc00f1409d36826df1665df27 Author: HyeongJun An Date: Tue Jun 9 21:43:13 2026 +0900 ASoC: codecs: hdac_hdmi: Validate written enum value [ Upstream commit 0b08baeccdcf52fad328ad645f5b4fbee04eea34 ] hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value. Fixes: 4a3478debf36 ("ASoC: hdac_hdmi: Add jack reporting") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260609124317.38046-2-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 544ee81c23da1ff1fb7f711446a409be8adbc313 Author: Arnd Bergmann Date: Thu Jun 11 15:23:06 2026 +0200 ASoC: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly [ Upstream commit 999ec4c29d73ac85b639a31bbc85ad2ec00eb9d7 ] When SND_SOC_SOF_INTEL_LNL is set, SND_SOF_SOF_HDA_SDW_BPT must also be enabled, in order to let the soundwire support call into it. However, there are configurations with SND_SOF_SOF_HDA_SDW_BPT=m and SND_SOF_SOF_HDA_SDW_BPT=m but SOUNDWIRE_INTEL=y, which still lead to a link failure: aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_wait': intel_ace2x.c:(.text+0xfc8): undefined reference to `hda_sdw_bpt_wait' aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_send_async': intel_ace2x.c:(.text+0x1ff8): undefined reference to `hda_sdw_bpt_get_buf_size_alignment' Address this by moving the 'select SND_SOF_SOF_HDA_SDW_BPT' into SND_SOC_SOF_HDA_GENERIC. Fixes: 614d416dd8ae ("ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260611132310.137688-2-arnd@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ace130dae7023eb31b4ef3da4f00699a7c433b13 Author: Arnd Bergmann Date: Thu Jun 11 15:23:05 2026 +0200 ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from SND_SOC_SOF_HDA_GENERIC=y [ Upstream commit 67805f57e5b1a8589f89bd48936c65cbbaeec300 ] When SND_SOC_SOF_HDA_GENERIC=y but SND_SOC_SOF_INTEL_SOUNDWIRE=m, the SND_SOC_SDW_UTILS is also set to =m even though there is a direct link dependency from the hda.c: aarch64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_machine_select': hda.c:(.text+0x21ac): undefined reference to `codec_info_list' hda.c:(.text+0x241c): undefined reference to `asoc_sdw_get_dai_type' hda.c:(.text+0x25b4): undefined reference to `asoc_sdw_get_codec_info_list_count' hda.c:(.text+0x25d8): undefined reference to `asoc_sdw_get_codec_info_list_count' Change this the same way as the other related 'select' statements to allow linking against it. Fixes: 2b4d53eb5cf3 ("ASoC: SOF: Intel: select SND_SOC_SDW_UTILS in SND_SOC_SOF_HDA_GENERIC") Signed-off-by: Arnd Bergmann Tested-by: Julian Braha Link: https://patch.msgid.link/20260611132310.137688-1-arnd@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c180cb20e0065ff0d2dd0df42d0df33569db977f Author: Richard Fitzgerald Date: Thu Jun 11 16:12:34 2026 +0100 ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer() [ Upstream commit 3073eb1f1143deabbda6a043238ab9d99672e7c8 ] In cs35l56_cal_data_debugfs_write() fix the if statement that checks for error return to only check for negative values. Reported by Sashiko: simple_write_to_buffer() returns the positive number of bytes copied on success. Since the condition returns immediately on any non-zero value, is it possible that the written calibration data is discarded and cs35l56_stash_calibration() is never called? Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration") Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260610093432.557375-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260611151234.1111153-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ef369446f62903ea079e8a7954b5bf8bb8300fe3 Author: Leon Romanovsky Date: Thu Jun 11 13:20:15 2026 +0300 RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one [ Upstream commit 449ae7927152e46acbe5f19f97eafdae6d3a96b1 ] Free the UAR index returned by the hardware. Fixes: 4ed131d0bb15 ("IB/mlx5: Expose dynamic mmap allocation") Link: https://patch.msgid.link/r/20260611-fix-uar-release-v1-1-f5464d845dbf@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b732db02a2b04cde393638df19de6251ce62a74e Author: Maher Sanalla Date: Thu Jun 11 15:50:42 2026 +0300 RDMA/mlx5: Fix undefined shift of user RQ WQE size [ Upstream commit d881d60223aac8fdc12b227d89c76e131e92a9cd ] set_rq_size() computes the RQ WQE size as "1 << rq_wqe_shift" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://patch.msgid.link/r/20260611-maher-sec-fixes-v1-1-cd8eb2542869@nvidia.com Signed-off-by: Maher Sanalla Signed-off-by: Edward Srouji Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 90488804bcf44644763e4ebed39096b5c021e95c Author: Patrisious Haddad Date: Sun Jun 7 21:18:09 2026 +0300 RDMA/mlx5: Remove raw RSS QP restrack tracking [ Upstream commit 666031fed8f0fdfc29b20d125a628c1b0a04cdaf ] Raw RSS QP restrack tracking wasn't working to begin with as it was only tracking the first raw RSS QP which was added, since at creation the raw RSS QP number is reserved so the QP number for this qp type was always zero. The following raw RSS QP additions were always failing silently. Since the fix isn't trivial and there were no users that required or complained about this issue we are dropping this for now instead of fixing. Fixes: 968f0b6f9c01 ("RDMA/mlx5: Consolidate into special function all create QP calls") Link: https://patch.msgid.link/r/20260607-restrack-uaf-fix-v1-2-d72e45eb76c2@nvidia.com Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 91088093cb00abd5ad3681ed95fd73949f56a689 Author: Patrisious Haddad Date: Sun Jun 7 21:18:08 2026 +0300 RDMA/mlx5: Remove DCT restrack tracking [ Upstream commit b136a7af41f796a48665afc6a55907488a3d5500 ] DCT restrack tracking wasn't working to begin with as it was only tracking the first DCT which was added, since at creation the DCT number isn't yet initialized because the DCT FW object is only created during modify. The following DCT additions were failing silently. Since the fix isn't trivial and there were no users that required or complained about this issue we are dropping this for now instead of fixing. Fixes: fd3af5e21866 ("RDMA/mlx5: Track DCT, DCI and REG_UMR QPs as diver_detail resources.") Link: https://patch.msgid.link/r/20260607-restrack-uaf-fix-v1-1-d72e45eb76c2@nvidia.com Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ccb5dbc07de2e1fba55ff48780c7ebe3de046c07 Author: Maxwell Doose Date: Thu Jun 4 22:52:51 2026 -0500 fs: efs: remove unneeded debug prints [ Upstream commit 89009392c80da5da00876c8334ff20028e6e3eb6 ] The current code uses debug prints conditionally compiled with #ifdef DEBUG. However, that code, when compiled, causes compiler errors due to incompatible formatters and undefined variables, notably: fs/efs/file.c: In function `efs_get_block': fs/efs/file.c:26:35: error: `block' undeclared (first use in this function); did you mean `iblock'? 26 | __func__, block, inode->i_blocks, inode->i_size); | ^~~~~ and: fs/efs/file.c: In function `efs_bmap': ./include/linux/kern_levels.h:5:25: error: format `%ld' expects argument of type `long int', but argument 4 has type `blkcnt_t' {aka `long long unsigned int'} [-Werror=format=] 5 | #define KERN_SOH "\001" /* ASCII Start Of Header */ | ^~~~~~ which also extends to the other formatters. As this part of the code has been dead for just about 14 years now, it has not been modernized to stay compatible with the most recent gcc compilers. Fix these issues by removing the debug prints. Link: https://lore.kernel.org/20260605035251.89305-2-m32285159@gmail.com Fixes: f403d1dbac6d ("fs/efs: add pr_fmt / use __func__") Signed-off-by: Maxwell Doose Suggested-by: Andrew Morton Cc: Fabian Frederick Cc: Christian Brauner Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ac4b710e58ab9195a6b688f5d7f4dd80b41a94b0 Author: Michael Guralnik Date: Wed Jun 10 03:01:45 2026 +0300 RDMA/mlx5: Drop FRMR pool handle on UMR revoke failure [ Upstream commit c37d79dd967d450ea02e0ee2b6438b8534bbd044 ] When UMR revoke fails during MR cleanup, the handle is left in an unknown state and cannot be returned to the pool. The driver already destroys the mkey via the fallback path, but the pool's in_use counter is never decremented, drifting upward over time. Call ib_frmr_pool_drop on the revoke-failure path so the pool's accounting stays consistent with the handles it has handed out. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-10-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7800de33e1cb86aa28fdc6329edd93b4924d4ac3 Author: Michael Guralnik Date: Wed Jun 10 03:01:44 2026 +0300 RDMA/core: Add ib_frmr_pool_drop for unrecoverable handles [ Upstream commit ddbc251be18fb82884ee6e9af634cc9f1171a4d6 ] A driver that has popped a handle from an FRMR pool can hit failures that leave the handle in a state where it can't safely be returned for reuse. The driver destroys the handle itself, but the pool has no way to learn about it, so the in_use counter drifts upward. Add ib_frmr_pool_drop to balance the pool's accounting in this case. Every pop is now balanced by exactly one push or drop. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-9-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d9e9d10e56ab613fa74c47bd33f45ceed6988cc6 Author: Michael Guralnik Date: Wed Jun 10 03:01:43 2026 +0300 RDMA/core: Fix FRMR handle leak on push failure [ Upstream commit 8c76126b866649d8e8acc09a06f2b03b6ff88900 ] Failure to push a handle to the pool, caused by ENOMEM on queue page allocation, will trigger missing in_use counter update, skewing pool state indefinitely. Fix that by moving the handling of handle destruction in such case into the FRMR code, ensuring the handle is either pushed to the pool or destroyed inside the same function. Adjust mlx5_ib call site accordingly. Fixes: ce5df0b891ed ("IB/core: Introduce FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-8-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit eadccdba848c6ab9d5a020662c8e102d664a27b4 Author: Michael Guralnik Date: Wed Jun 10 03:01:42 2026 +0300 RDMA/core: Avoid NULL dereference on FRMR bad usage [ Upstream commit 3937243095b5cfed6556bd1ea170790223f3eeb0 ] In case a driver calls FRMR pop operation without a successful init, return after triggering a warning to avoid the NULL dereference. Fixes: ce5df0b891ed ("IB/core: Introduce FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-7-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a487c14dda02a649d84c8303772430d32bd76eb9 Author: Michael Guralnik Date: Wed Jun 10 03:01:41 2026 +0300 RDMA/core: Fix FRMR set pinned push error path [ Upstream commit 41a707d0275cdec9ac125e826dd6836fa9623cbc ] Add destruction of FRMR handles in case the push to the pool fails. This prevents resources leak in case pool page allocation fails. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-6-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Reviewed-by: Tao Cui Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit edf133d28fc43f7f8b0da43a8d5b93fdf8073d35 Author: Michael Guralnik Date: Wed Jun 10 03:01:40 2026 +0300 RDMA/core: Fix FRMR aging push to queue error flow [ Upstream commit c6936506ed556ce3ccad36ab999baf2764dd7d25 ] Aging pools with pinned handles requires moving handles from the active queue to a non-empty inactive queue that might fail on new page allocation, we are currently not handling the fault and leaking any mkey that fails the push. Fix by Introducing push_queue_to_queue_locked() that fills the destination's partial tail page from the source and then splices the remaining source pages onto the destination, performing no allocation. Replace the per-handle move loop in age_pinned_pool() and the open-coded splice in pool_aging_work() with calls to the helper. As the helper cannot fail under memory pressure, removing a class of GFP_ATOMIC allocations under the pool lock and simplifying the error flow. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-5-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 97fa194ba9a66fc464897d7752c212ebcc7ff6cb Author: Michael Guralnik Date: Wed Jun 10 03:01:39 2026 +0300 RDMA/core: Fix skipped usage for driver built FRMR key [ Upstream commit 3d7fd88aeff73f25ee740b3a65a3b4dd38ad7783 ] When creating FRMR handles following a netlink command to pin handles, use the key after driver callback instead of using the key passed directly from user. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-4-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 220a32cd43c4814f680257b026d70f8f78210f16 Author: Michael Guralnik Date: Wed Jun 10 03:01:38 2026 +0300 RDMA/mlx5: Fix TPH extraction in FRMR pool key [ Upstream commit fe683274fee497834d2e6b54b7342642e1f21892 ] Fix reading the PH value from the FRMR pool key by shifting the pool key to the relevant bits. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-3-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8386cf70210a1506d767be3158c593b4d00e29f2 Author: Michael Guralnik Date: Wed Jun 10 03:01:37 2026 +0300 RDMA/mlx5: Fix mkey creation error flow rollback [ Upstream commit c70fcfa9881207659ad193ae10a3bd56b2ae3f8a ] Fix the indices of mkeys destroyed in case of an error in batch mkey creation. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-2-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a64e19774f213c5ccd9114a83db84dceac9dffd4 Author: Samuel Moelius Date: Mon Jun 8 23:58:23 2026 +0000 Bluetooth: vhci: validate devcoredump state before side effects [ Upstream commit 88c2404a3c59c3126453919388dbd5ed98ed01bd ] The VHCI force_devcoredump debugfs hook accepts a small test record from userspace. It validates the requested terminal state only after registering, initializing and appending a Bluetooth devcoredump. As a result, an invalid state returns -EINVAL but still leaves queued devcoredump work behind. With a non-zero timeout field, the rejected write can still emit a devcoredump after the timeout expires. Reject unsupported states before allocating the skb or changing the HCI devcoredump state machine. Fixes: ab4e4380d4e1 ("Bluetooth: Add vhci devcoredump support") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4bc16db0f11918e07edf9fdcda4a30cf4c9df45c Author: Samuel Moelius Date: Mon Jun 8 23:56:28 2026 +0000 Bluetooth: hci: validate codec capability element length [ Upstream commit c38fbcdc407925c7088f7e5f11c1fff73d2d35a2 ] Read Local Codec Capabilities returns a sequence of capability elements. Each element starts with a one-byte length followed by that many payload bytes. hci_read_codec_capabilities() checks that the skb contains the length byte, but then validates only caps->len against the remaining skb length. A malformed controller response with one remaining byte and caps->len set to one passes that check even though the element needs two bytes. The parser then records a two-byte capability and copies one byte beyond the advertised response payload into the codec list. Validate the full element size, including the length byte, before adding it to the accumulated capability length. This preserves all well-formed capability elements and drops only truncated controller responses. Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5cdc6763279b0eb704a4fa88d66d65fadf577f10 Author: Sai Teja Aluvala Date: Sun Jun 7 11:51:17 2026 +0530 Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant [ Upstream commit e43b33bf8d671c50a45fe5f487819927595bbd50 ] Load the IOSF DBGC base address based on the controller hardware variant when reading DRAM buffers during a trace dump. Scorpius Peak family controllers (SCP/SCP2/SCP2F) use a different DBGC base address (0xf0d5d500) than Blazar family controllers (BZRI/BZRIW, 0xf3800300). Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump") Signed-off-by: Sai Teja Aluvala Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4e354991da5890d5ce7bfea3f66fb897ae301756 Author: Zhao Dongdong Date: Thu Jun 4 19:46:40 2026 +0800 Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path [ Upstream commit f396f4005180928cd9e15e352a6512865d3bc908 ] When btmtk_isopkt_pad() fails, the previously allocated URB is not freed, leaking the urb structure. Add usb_free_urb() before returning the error. Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Zhao Dongdong Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 672d52d9412252e61b8de8d773ccdf5a277cf540 Author: Jordan Walters Date: Wed Jun 3 04:50:47 2026 -0400 Bluetooth: hci_core: Fix UAF in hci_unregister_dev() [ Upstream commit 5edcc018fa6e80b2c478454a4a8229c23d67c181 ] hci_unregister_dev() does not disable cmd_timer and ncmd_timer before the hci_dev structure is freed. If a timeout fires during device teardown, the callback dereferences freed memory (including the hdev->reset function pointer), leading to a use-after-free. Add disable_delayed_work_sync() calls alongside the existing disable_work_sync() calls to ensure both timers are fully quiesced before teardown proceeds. Fixes: 0d151a103775 ("Bluetooth: hci_core: cancel all works upon hci_unregister_dev()") Signed-off-by: Jordan Walters Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e4053143e7dc0c86958351e81d618ffc42302828 Author: Jiajia Liu Date: Tue Jun 2 15:00:32 2026 +0800 Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING [ Upstream commit 96d006ae6445679436b945593950fd465eba7e76 ] When hci_inquiry_complete_evt is called between le_scan_disable and le_set_scan_enable_complete and no remote name needs to be resolved, the interleaved discovery with SIMULTANEOUS quirk gets stuck in DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry state. No one sets DISCOVERY_STOPPED in this process. Add state check in le_set_scan_enable_complete and change state if the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell Vostro 13. Discovering disabled MGMT Event below is reported when running into the above condition. @ MGMT Command: Start Discovery (0x0023) {0x0001} [hci0] 10885.970873 Address type: 0x07 BR/EDR LE Public LE Random ... < HCI Command: LE Set Extended Scan Enable #38205 [hci0] 10886.131438 Extended scan: Enabled (0x01) Filter duplicates: Enabled (0x01) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Command Complete (0x0e) plen 4 #38206 [hci0] 10886.133295 LE Set Extended Scan Enable (0x08|0x0042) ncmd 2 Status: Success (0x00) @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10886.133414 Address type: 0x07 BR/EDR LE Public LE Random Discovery: Enabled (0x01) < HCI Command: Inquiry (0x01|0x0001) plen 5 #38207 [hci0] 10886.133528 Access code: 0x9e8b33 (General Inquiry) Length: 10.24s (0x08) Num responses: 0 > HCI Event: Command Status (0x0f) plen 4 #38208 [hci0] 10886.141333 Inquiry (0x01|0x0001) ncmd 2 Status: Success (0x00) ... < HCI Command: LE Set Extended Scan Enable #38242 [hci0] 10896.381802 Extended scan: Disabled (0x00) Filter duplicates: Disabled (0x00) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Inquiry Complete (0x01) plen 1 #38243 [hci0] 10896.383419 Status: Success (0x00) > HCI Event: Command Complete (0x0e) plen 4 #38244 [hci0] 10896.394378 LE Set Extended Scan Enable (0x08|0x0042) ncmd 2 Status: Success (0x00) @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497 LE Address: 88:12:AC:92:43:69 RSSI: -101 dBm (0x9b) Flags: 0x00000004 Not Connectable Data length: 8 Company: Xiaomi Inc. (911) Data[0]: 16-bit Service UUIDs (complete): 1 entry Xiaomi Inc. (0xfdaa) @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10896.394506 Address type: 0x07 BR/EDR LE Public LE Random Discovery: Disabled (0x00) Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync") Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 57077eeb586c42f124bc09e018449362223067b3 Author: Weiming Shi Date: Wed Jun 3 01:06:21 2026 +0800 Bluetooth: eir: Fix stack OOB write when prepending the Flags AD [ Upstream commit 6f5fb689fdf80bdd143f22a502f9eb1f3c85e286 ] eir_create_adv_data() builds the advertising data into a fixed-size buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags" AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies the per-instance data without checking that it still fits: memcpy(ptr, adv->adv_data, adv->adv_data_len); tlv_data_max_len() only reserves those 3 bytes when the user-supplied flags carry a managed-flags bit, so an instance added with flags == 0 is accepted with adv_data_len up to the full buffer. At advertise time the flags are still prepended, and the memcpy() writes 3 + adv_data_len bytes into the size-byte buffer: BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301) Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65 Workqueue: hci0 hci_cmd_sync_work __asan_memcpy (mm/kasan/shadow.c:106) eir_create_adv_data (net/bluetooth/eir.c:301) hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310) hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817) hci_cmd_sync_work (net/bluetooth/hci_sync.c:332) This frame has 1 object: [32, 64) 'cp' The "Flags" structure is added by the kernel, not requested by userspace, so only prepend it when it fits together with the instance advertising data; when there is no room for both, drop the flags rather than the user-provided data. Reachable by a local user with CAP_NET_ADMIN owning an LE-only controller on the legacy advertising path. Fixes: b44133ff03be ("Bluetooth: Support the "discoverable" adv flag") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Reported-by: Xiang Mei Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d54a5fb7d821b88c7c5569d450af59dafccaf414 Author: Zijun Hu Date: Mon Jun 1 04:30:56 2026 -0700 Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for non-serdev device [ Upstream commit 6b8cbcf08de0db62254d1981f83db0f94681ccd9 ] hu->serdev is NULL for hci_uart attached via non-serdev paths, but qca_dmp_hdr() unconditionally dereferences hu->serdev->dev.driver->name, causing a NULL pointer dereference. Fix by guarding the dereference with a NULL check and falling back to "hci_ldisc_qca" for the non-serdev case. Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0704c04769ccc1a0939682db35d816dfa5fe75dc Author: Zijun Hu Date: Mon Jun 1 04:30:55 2026 -0700 Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-serdev device [ Upstream commit 3ec629fee178d429f01ae843e4ea888de93012bf ] hu->serdev is NULL for hci_uart attached via non-serdev paths, but qca_setup() unconditionally calls serdev_device_get_drvdata(hu->serdev) and dereferences the result, causing a NULL pointer dereference. Fix by guarding the dereference with a NULL check, consistent with the rest of qca_setup(). Fixes: 22d893eec0d5 ("Bluetooth: hci_qca: Refactor HFP hardware offload capability handling") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 27798cc01c28acbdaf2151185ed742b9d86dd41c Author: Heiko Carstens Date: Mon Jun 8 16:19:08 2026 +0200 s390/process: Fix kernel thread function pointer type [ Upstream commit d0478f5d3cba1095bfdeb43a9b063c10cdebef14 ] In case of a kernel thread __ret_from_fork() calls the specified function indirectly. Fix the kernel thread function pointer, since kernel threads return an int instead of void. Fixes: 56e62a737028 ("s390: convert to generic entry") Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit d657d18d1c699b0b8cf0b5b8bddf71ec70a7b194 Author: Richard Fitzgerald Date: Thu Jun 11 14:22:21 2026 +0100 ASoC: cs35l56: Fix possible uninitialized value in cs35l56_spi_system_reset() [ Upstream commit 007699d278a655871b07d45a1268761260d03124 ] In cs35l56_spi_system_reset() initialize val to zero before using it in the read_poll_timeout(). This prevents testing an uninitialized value if the regmap_read_bypassed() returns an error. Read errors are intentionally ignored during this loop because the device is resetting (though SPI can't really detect that so shouldn't fail because of that, it's safer to ignore errors and keep polling). Because of this, val must be initialized to something in case the first read fails. The polling loop is looking for a non-zero value, so initializing val to 0 will ensure that the loop continues until a valid state is read from the device or it times out. Fixes: 769c1b79295c ("ASoC: cs35l56: Prevent races when soft-resetting using SPI control") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260611132221.1100497-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dc450743c42e600dd2feb9661c2c3358de427fcd Author: Andre Przywara Date: Fri Mar 27 11:30:06 2026 +0000 arm64: dts: allwinner: a523: Add missing GPIO interrupt [ Upstream commit 6b81aa0c8a4f038712fa549e4d44d8279eeb0440 ] Even though the Allwinner A523 SoC implements 10 GPIO banks, it has actually registers for 11 IRQ banks, and even an interrupt assigned to the first, non-implemented IRQ bank. Add that first interrupt to the list of GPIO interrupts, to correct the association between IRQs and GPIO banks. This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by broken SD card detect functionality, for instance. Signed-off-by: Andre Przywara Fixes: 35ac96f79664 ("arm64: dts: allwinner: Add Allwinner A523 .dtsi file") Reviewed-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260327113006.3135663-4-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 30d6552f7d8c4fd8fd4f198eea7a5f7035e9c615 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:42 2026 +0300 pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function [ Upstream commit 7b87a686a5ab138b3f8ca3d7e3489d8371c02695 ] pcm_spi_int, pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4 pin groups are not defined, so pcm_spi function can't be applied to these groups. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 82cc075fc3d9dea538eecc6afa02724ac71b4547 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:41 2026 +0300 pinctrl: airoha: an7583: fix phy1_led1 pin function [ Upstream commit dbe28a2a22a3455d1adbf9fd61d3537603ac3072 ] phy1_led1 pin function wrongly refers to gpio1 instead of gpio11. Fix it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0b3e0c425ea9358ff180f415a941fc9207d2b796 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:40 2026 +0300 pinctrl: airoha: an7583: add missed gpio22 pin group [ Upstream commit 9ef86358855d5fd89db019ace33c097d2d752b9d ] gpio22 pin group is missed, fix it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0b30b5305fd76281d16f696a88de4b251af10a58 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:39 2026 +0300 pinctrl: airoha: an7583: fix gpio21 pin group [ Upstream commit abf92c45cc82e9a01aa581f9fbc790e78250a4d4 ] gpio21 pin group refers to gpio22 pin, this is wrong. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5ec8f823ec2a0df83bbbb4dc8f4052d3ab3e496d Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:38 2026 +0300 pinctrl: airoha: fix pwm pin function for an7581 and an7583 [ Upstream commit 08a5af468e613b6d8cd9725d284c9e6be288d364 ] AN7581 have 47 valid GPIOs only (gpio0-gpio46), so gpio47 is a fiction. AN7583 have 49 valid GPIOs (gpio0-gpio48), so gpio48 is missed To fix an issue * create AN7583 specific pwm pin function, * remove gpio47 from AN7581 pwm pin function. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1d494be03832c0bdce90256845043761d23ab398 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:37 2026 +0300 pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function [ Upstream commit a3602577fdfc49c6dc08d67304426d5ef6d7dec6 ] phy4_led1 pin function maps led incorrectly. It uses the same map as phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1). Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 98977e9a78d712d572c9606467f2a075457e57a9 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:36 2026 +0300 pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function [ Upstream commit e20c85c79cc2f45b87eb3dab38d4c641bbf83ed6 ] phy4_led1 pin function maps led incorrectly. It uses the same map as phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1). Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 38208826f4bc3e698f413ca7ee391397d502c56d Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:35 2026 +0300 pinctrl: airoha: an7583: fix misprint in gpio19 pinconf [ Upstream commit a7f3e2b7730fc1d6c7431af49e0dc1ee97589795 ] Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using a proper bit number in the configuration register. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f880faa7c6dac1cb74379bf886fabc77aec1ece1 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:34 2026 +0300 pinctrl: airoha: an7581: fix misprint in gpio19 pinconf [ Upstream commit 08a39a0617ff32a7c3962bbc38a9eee41b14659a ] Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using a proper bit number in the configuration register. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d59971decbd3bcfa12ae7695d08fbb0c68f719d0 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:33 2026 +0300 pinctrl: airoha: an7583: add missed gpio32 pin group [ Upstream commit 81cc2285cea84e3ed8688d353e1250cf8899c80a ] gpio32 pin group is missed for an7583 SoC. This patch add it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8de35c96965a70af5be8ec5e1bbb9116ca6f96f2 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:32 2026 +0300 pinctrl: airoha: an7581: add missed gpio32 pin group [ Upstream commit bdc95d7e8de3eefa9fc062302625259c0b79136d ] gpio32 pin group is missed for an7581 SoC. This patch add it. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bcd974652a914e639cf662b501be2c05684c73fc Author: Andre Przywara Date: Fri Mar 27 11:30:04 2026 +0000 pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag [ Upstream commit eaf84ff673409fa3dfc390c6afb53b641ee5acba ] The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when that line is muxed for IRQ triggering (muxval 6), but only if it's explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this behaviour, so we added a optional workaround, triggered by a quirk bit, which triggers remuxing the pin when it's configured for IRQ, while we need to read its value. For some reasons this quirk flag was copied over to newer SoCs, even though they don't show this behaviour, and the GPIO data register reflects the true GPIO state even with a pin muxed to IRQ trigger. Remove the unneeded quirk from the A523 family, where it's definitely not needed (confirmed by experiments), and where it actually breaks, because the workaround is not compatible with the newer generation pinctrl IP used in that chip. Together with a DT change this fixes GPIO IRQ operation on the A523 family of SoCs, as for instance used for the SD card detection. Signed-off-by: Andre Przywara Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports") Reviewed-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f7751e4e9d347406322c2d7d9db904958ef9502b Author: Angelo Dureghello Date: Wed Jun 10 22:35:06 2026 +0200 m68k: mcf5441x: fix clocks numbering [ Upstream commit 919afb86694f5a8a9b50bff56cd8199f065b0dbb ] Fix clocks numbering, set correct values for eport and DAC, as per RM Rev 5, 05/2018, table 9.5. Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.") Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put") Signed-off-by: Angelo Dureghello Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit cb22dc79528eb26a46d346c3118dbd6b14c70609 Author: Daniel Borkmann Date: Wed Jun 10 12:55:38 2026 +0200 bpf: Tighten cgroup storage cookie checks for prog arrays [ Upstream commit 10627ddc0167aab5c1c390a10ef461e9937aba08 ] The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge. Fixes: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") Reported-by: Lin Ma Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260610105539.705887-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b6fd7a40a66485c8aa8156d8fcf50b95cb8ba281 Author: Giovanni Cabiddu Date: Mon Jun 8 16:12:57 2026 +0100 vfio/qat: fix f_pos race in qat_vf_resume_write() [ Upstream commit 4ec5e932e636896e97e4c6a8205b0ac76d52421a ] qat_vf_resume_write() checks filp->f_pos before taking migf->lock, but copies into the migration-state buffer after taking the lock and re-reading the shared file position. Two concurrent writers could therefore pass the bounds check with the old offset, then have the second writer copy after the first advanced f_pos, writing past the end of the migration-state buffer. Take migf->lock before doing the boundary checks. Fixes: bb208810b1ab ("vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF devices") Reviewed-by: Ahsan Atta Signed-off-by: Giovanni Cabiddu Link: https://lore.kernel.org/r/20260608151317.136613-1-giovanni.cabiddu@intel.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit bfc8eddca6ec274df6517cb73ba8a137e502c13b Author: Sergey Shtylyov Date: Wed Apr 29 23:14:39 2026 +0300 of: cpu: add check in __of_find_n_match_cpu_property() [ Upstream commit 5901eda2ed99ba0d3661da6eb265970559323bb3 ] In __of_find_n_match_cpu_property(), checking the variable ac for 0 won't prevent a possible overflow when multiplying it by sizeof(*cell). Besides, of_read_number() (called in the *for* loop) can't return correct result if that variable (which equals the #address-cells prop's value) exceeds 2, so additionally checking for that seems logical... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: f3cea45a77c8 ("of: Fix iteration bug over CPU reg properties") Signed-off-by: Sergey Shtylyov Link: https://patch.msgid.link/0c7bf7e9-887c-42d5-bcfb-0ba7fe1e70b6@auroraos.dev Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit d881369a8553f9e75bfaf32f291839e34bc3e804 Author: Dave Jiang Date: Fri Jun 5 11:44:26 2026 -0700 cxl/test: Zero out LSA backing memory to avoid leaking to user [ Upstream commit 60f065dbaf46e65830da62a0041761f0c039e086 ] Memory through vmalloc() is not zeroed out. When this memory is copied into output payload, it leaks memory content to user. Use vzalloc() instead to zero out the memory. Suggested-by: sashiko-bot Link: https://lore.kernel.org/linux-cxl/20260605173146.2B9A31F00893@smtp.kernel.org/ Fixes: 7d3eb23c4ccf ("tools/testing/cxl: Introduce a mock memory device + driver") Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260605184426.4070913-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 206895bd3e88a236efabf63e92902e19ae4c5a94 Author: Dave Jiang Date: Fri Jun 5 10:12:38 2026 -0700 cxl/test: Fix integer overflow in mock LSA bounds checks [ Upstream commit 81eafcada109b653977c4dfbd2b6a72470025a01 ] Pre-existing issue discovered by sashiko-bot. mock_get_lsa() and mock_set_lsa() validate the requested LSA range with "offset + length > LSA_SIZE". Both offset and length are u32 and, in mock_get_lsa(), both are taken directly from the user-supplied payload. The addition is evaluated modulo 2^32, so a large offset combined with a small length wraps around and passes the check. Rewrite the checks to first bound offset, then compare length against the remaining LSA size. Suggested-by: sashiko-bot Fixes: 7d3eb23c4ccf ("tools/testing/cxl: Introduce a mock memory device + driver") Link: https://lore.kernel.org/linux-cxl/20260605143748.235271F00893@smtp.kernel.org/ Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 87f734a444cffa3ea12499d682386469c0e47710 Author: Dave Jiang Date: Fri Jun 5 11:15:08 2026 -0700 cxl/test: Verify cmd->size_in before accessing payload [ Upstream commit 71a1def165267bc0947d4236f7336f490739c379 ] Several mock mailbox handlers access input payload fields before verifying that cmd->size_in is large enough for the corresponding structure. To ensure invalid commands are rejected before any payload data is consumed, add missing size checks and move existing checks ahead of the first payload field access. [dj: Updated commit log per Alison's comments. ] Fixes: 7d3eb23c4ccf ("tools/testing/cxl: Introduce a mock memory device + driver") Fixes: d1dca858f058 ("cxl/test: Add generic mock events") Fixes: f6448cb5f2f3 ("tools/testing/cxl: add firmware update emulation to CXL memdevs") Fixes: e77e9c107978 ("cxl/test: Add Get Feature support to cxl_test") Link: https://lore.kernel.org/linux-cxl/20260605143748.235271F00893@smtp.kernel.org/ Suggested-by: sashiko-bot Tested-by: Alison Schofield Reviewed-by: Alison Schofield Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit fbbd7604fdf105a421ba6503d43259b4301e3283 Author: Yonghong Song Date: Tue Jun 9 22:18:31 2026 -0700 selftests/bpf: Fix bpf_iter/task_vma test [ Upstream commit 2e8ad1ff712d2a397e407c9fde60901f68d077dc ] For selftest bpf_iter/task_vma, I got a failure like below on my qemu run: test_task_vma_common:FAIL:compare_output unexpected compare_output: actual '561593546000-561593585000r--p0000000000:241256579534/root/devshare/bpf-next/tools/testing/selftests/bpf/test_progs' != expected '561593546000-561593585000r--p0000000000:245551546830/root/devshare/bpf-next/tools/testing/selftests/bpf/test_progs' Further debugging found out file->f_inode->i_ino value may exceed 32bit, e.g., i_ino = 0x14c2eae35, but the format string is '%u'. This caused inode mismatch between bpf iter and proc result. Fix the issue by using format string '%llu' to accommodate 64bit i_ino. Fixes: e8168840e16c ("selftests/bpf: Add test for bpf_iter_task_vma") Signed-off-by: Yonghong Song Acked-by: Leon Hwang Link: https://lore.kernel.org/r/20260610051831.1346659-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fb52013cad9e9b7d3a6a14ea1bcd841e41da7c6c Author: Yun Zhou Date: Mon Jun 8 23:25:21 2026 +0800 ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT [ Upstream commit c143957520c6c9b5cd72e0de8b52b814f0c576fe ] Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not belong to the same superblock as the original file. Currently, this validation is performed inside ext4_move_extents() by mext_check_validity(), but only after lock_two_nondirectories() has already acquired the inode locks. When the donor fd refers to a file on a different filesystem (e.g., overlayfs), this late validation creates a circular lock dependency: CPU0 (overlayfs write) CPU1 (ext4 ioctl) ---- ---- inode_lock(ovl_inode) mnt_want_write_file(filp) sb_start_write(ext4_sb) [sb_writers] backing_file_write_iter() vfs_iter_write(real_file) file_start_write(real_file) sb_start_write(ext4_sb) [blocked by freeze] lock_two_nondirectories() inode_lock(ovl_inode) [blocked] With a concurrent freeze operation holding sb_writers write side, this forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock. Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files, it fundamentally requires both files to reside on the same ext4 filesystem. Moving the superblock check before any lock acquisition is both semantically correct and eliminates the circular dependency by ensuring that cross-filesystem donor fds are rejected before sb_writers or inode locks are taken. Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base") Reported-by: syzbot+ad6118a7584b607c67f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ad6118a7584b607c67f2 Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20260608152521.1292656-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0ae42b51607240990614e0843f0d3529aaff62cc Author: Aditya Prakash Srivastava Date: Mon Jun 8 06:52:27 2026 +0000 ext4: fix kernel BUG in ext4_write_inline_data_end [ Upstream commit ad09aa45965d3fafaf9963bc78109b73c0f9ac8d ] When the data=journal mount option is used, the ext4_journalled_write_end() function incorrectly calls ext4_write_inline_data_end() without checking if the EXT4_STATE_MAY_INLINE_DATA flag is still set on the inode. If a previous attempt to convert the inline data to an extent failed (e.g. due to ENOSPC), the EXT4_STATE_MAY_INLINE_DATA flag is cleared, but the EXT4_INODE_INLINE_DATA flag remains set. In this scenario, the next call to ext4_write_begin() will not prepare the inline data xattr for writing, but ext4_journalled_write_end() will incorrectly attempt to write to it, triggering a BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) in ext4_write_inline_data() since i_inline_size was not expanded. Fix this by ensuring that ext4_journalled_write_end() only calls ext4_write_inline_data_end() if the EXT4_STATE_MAY_INLINE_DATA flag is set, mirroring the behavior of ext4_write_end() and ext4_da_write_end(). Reported-by: syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c89d865531d053abb2d Fixes: 3fdcfb668fd7 ("ext4: add journalled write support for inline data") Signed-off-by: Aditya Prakash Srivastava Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260608065227.3018-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit fa466bc24aa64c3b9210904db61fef16be2f0cf9 Author: Louis Scalbert Date: Wed Jun 3 17:03:30 2026 +0200 bonding: 3ad: fix mux port state on oper down [ Upstream commit 807afc7544b865d4d09068a415fd5b71bf5665cc ] When the bonding interface has carrier down due to the absence of usable slaves and a slave transitions from down to up, the bonding interface briefly goes carrier up, then down again, and finally up once LACP negotiates collecting and distributing on the port. When lacp_strict mode is on, the interface should not transition to carrier up until LACP negotiation is complete. This happens because the actor and partner port states remain in Collecting_Distributing when the port goes down. When the port comes back up, it temporarily remains in this state until LACP renegotiation occurs. Previously this was mostly cosmetic, but since the bonding carrier state may depend on the LACP negotiation state, it causes the interface to flap. According to IEEE 802.3ad-2000 and IEEE 802.1ax-2014, Collecting and Distributing should be reset when a port goes down: - In the Receive state machine, port_enabled == FALSE causes a transition to the PORT_DISABLED state, which is expected to clear Partner_Oper_Port_State.Synchronization. - In the Mux state machine, Partner_Oper_Port_State.Synchronization == FALSE causes a transition to the ATTACHED state, which disables Collecting and Distributing. However, Partner_Oper_Port_State.Synchronization is not cleared in the PORT_DISABLED state. Clear Partner_Oper_Port_State.Synchronization in the Receive PORT_DISABLED state. Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad") Signed-off-by: Louis Scalbert Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260603150331.1919611-6-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd35901594aea87072eef8dea0c3cd0a43babca8 Author: Louis Scalbert Date: Wed Jun 3 17:03:29 2026 +0200 bonding: 3ad: fix carrier when no usable slaves [ Upstream commit 0bd695db23c6262e9cb980017a6273925172ec5b ] Apply the "lacp_strict" configuration from the previous commit. "lacp_strict" mode "on" asserts that the bonding master carrier is up only when at least 'min_links' slaves are in the Collecting_Distributing state. Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad") Signed-off-by: Louis Scalbert Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260603150331.1919611-5-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4edbd91f4f97dfa9df875f429b08c0dc4fe209b8 Author: Louis Scalbert Date: Wed Jun 3 17:03:28 2026 +0200 bonding: 3ad: add lacp_strict configuration knob [ Upstream commit 32b0b8953343eaceaa816a9ead3b6bb66355c64e ] When an 802.3ad (LACP) bonding interface has no slaves in the collecting/distributing state, the bonding master still reports carrier as up as long as at least 'min_links' slaves have carrier. In this situation, only one slave is effectively used for TX/RX, while traffic received on other slaves is dropped. Upper-layer daemons therefore consider the interface operational, even though traffic may be blackholed if the lack of LACP negotiation means the partner is not ready to deal with traffic. Introduce a configuration knob to control this behavior. It allows the bonding master to assert carrier only when at least 'min_links' slaves are in Collecting_Distributing state. The default mode preserves the existing behavior. This patch only introduces the knob; its behavior is implemented in the subsequent commit. Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad") Signed-off-by: Louis Scalbert Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260603150331.1919611-4-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7caa5f615e0bac22daac7c1f1dce293e2a56ddd9 Author: Louis Scalbert Date: Wed Jun 3 17:03:27 2026 +0200 netlink: specs: rt-link: missed broadcast-neigh [ Upstream commit 363037983cc503eb0b5a5c0ab80bf1434cfd168a ] Add missed broadcast-neigh. Signed-off-by: Louis Scalbert Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260603150331.1919611-3-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski Stable-dep-of: 32b0b8953343 ("bonding: 3ad: add lacp_strict configuration knob") Signed-off-by: Sasha Levin commit b10839d1d0aff96a0f60a4af8c674a2704560d68 Author: Louis Scalbert Date: Wed Jun 3 17:03:26 2026 +0200 tools: missed broadcast_neigh if_link uapi header [ Upstream commit 0134432215f0e0d4526544ac63dabe20e8a6951e ] Add missing IFLA_BOND_BROADCAST_NEIGH in if_link uapi header. Signed-off-by: Louis Scalbert Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260603150331.1919611-2-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski Stable-dep-of: 32b0b8953343 ("bonding: 3ad: add lacp_strict configuration knob") Signed-off-by: Sasha Levin commit 1b7831675b4040a22f8bc9133e781cc0ebaa92a8 Author: Hongling Zeng Date: Thu Jun 4 15:36:47 2026 +0800 ext4: fix ERR_PTR(0) in ext4_mkdir() [ Upstream commit 8e1c43af7cf5091d99db38b7c8129e394d7f45b5 ] When mkdir succeeds, ext4_mkdir() returns ERR_PTR(0) which is incorrect. It should return NULL instead for success and ERR_PTR() only with negative error codes for failure. Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260604073647.211279-1-zenghongling@kylinos.cn Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 881c149497c99f0d65307a482d6a0c1045514c4b Author: Pei Xiao Date: Wed Jun 10 09:49:12 2026 +0800 hwmon: (gpd-fan): fix race condition between device removal and sysfs access [ Upstream commit 1fb4397509bd8701d323e81ac9a97c2e24ed49eb ] Replace the manual gpd_fan_remove() callback with a devres-managed action using devm_add_action_or_reset(). The original remove hook resets the fan to AUTOMATIC mode, but the hwmon sysfs interface (registered with devm_hwmon_device_register_with_info()) remains active until after the remove callback completes. This creates a race window where a concurrent userspace sysfs access can interleave with the EC I/O sequence, potentially corrupting EC registers. Using devm_add_action_or_reset() registers the reset function as a devres action. Due to the LIFO release order of devres, the hwmon device is unregistered (sysfs removed) before the reset action executes, eliminating the race condition. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Signed-off-by: Pei Xiao Link: https://lore.kernel.org/r/4400828422cf3a88adad4db224d9efccdb1049d2.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit a8a4e60b137405824d07fff77d476f6543a0f247 Author: Pei Xiao Date: Wed Jun 10 09:49:10 2026 +0800 hwmon: (gpd-fan): Initialize EC before registering hwmon device [ Upstream commit a8a444917fe5d30a9787f41cc179f55fc5f559d3 ] Move the gpd_init_ec() call to before devm_hwmon_device_register_with_info in the probe function. With the previous ordering the hwmon device was registered and exposed to userspace before the EC initialization completes, creating a window where sysfs reads could return invalid values. Some buggy firmware won't initialize EC properly on boot. Before its initialization, reading RPM will always return 0, and writing PWM will have no effect. So move gpd_init_ec to before hwmon device register. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Signed-off-by: Pei Xiao Link: https://lore.kernel.org/r/4be3734b135c8013157979ab5e80c7ee51243ddd.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck Stable-dep-of: 1fb4397509bd ("hwmon: (gpd-fan): fix race condition between device removal and sysfs access") Signed-off-by: Sasha Levin commit 8fc88157a53ccbc0c0a560ebf22cd9049ed40797 Author: Pei Xiao Date: Wed Jun 10 09:49:09 2026 +0800 hwmon: (gpd-fan): drop global driver data and use per-device allocation [ Upstream commit 03b4addf8282fa2b63f2d7448d1a9bce9be3f556 ] replace the global state gpd_driver_priv with per-device private data (struct gpd_fan_data) allocated in probe. This allows the driver to support multiple instances in the future and aligns with kernel best practices. No functional change intended. Signed-off-by: Pei Xiao Link: https://lore.kernel.org/r/1cd3e13033fdd3d0f9b59322f7c86e350d113b92.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck Stable-dep-of: 1fb4397509bd ("hwmon: (gpd-fan): fix race condition between device removal and sysfs access") Signed-off-by: Sasha Levin commit eb8ff0201437449879357cb89bfc010c6055b1dc Author: Richard Fitzgerald Date: Wed Jun 10 11:55:56 2026 +0100 ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails [ Upstream commit 53cebeb017164254cde5e31c94d8deef9e4fff97 ] In cs35l56_system_suspend() re-enable the parent IRQ if the call to pm_runtime_force_suspend() returns an error. Fixes: f9dc6b875ec0 ("ASoC: cs35l56: Add basic system suspend handling") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260610105556.612830-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c78c8371f71968a826d9dca990795ac272b187b1 Author: Richard Fitzgerald Date: Wed Jun 10 10:34:32 2026 +0100 ASoC: cs35l56: Cleanup if component_probe fails [ Upstream commit a0df7522dfb098d56b42560247082d6f5a8581dd ] If cs35l56_component_probe() fails, call cs35l56_component_remove() to clean up. All the cleanup in cs35l56_component_remove() is the same cleanup that would need to be done (at least partially) if cs35l56_component_probe() fails. So calling cs35l56_component_remove() avoids convoluted cleanup gotos and duplicated code in cs35l56_component_probe(). The only action in cs35l56_component_remove() that is nominally dependent on having completed the component_probe() action is the call to wm_adsp2_component_remove(). Though it is currently safe to call that even if wm_adsp2_component_probe() was not called. However, wm_adsp2_component_probe() has been trivially updated to check itself whether it needs to cleanup. Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260610093432.557375-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 691edbf080289298f14b510117d4c4d5d508b0ff Author: Richard Fitzgerald Date: Wed Jun 10 10:34:31 2026 +0100 ASoC: cs35l56: Prevent double-free of debugfs [ Upstream commit 344a12ca7ba6e10f9779476780afe9d977d47322 ] Invalidate the debugfs pointer after debugfs_remove_recursive() in cs35l56_remove_cal_debugfs(). This prevents a double-free situation when a future commit adds proper failure cleanup in cs35l56_component_probe(). As described by Sashiko (including the future cs35l56_component_probe() cleanup commit): During a normal component unbind, cs35l56_component_remove() calls cs35l56_remove_cal_debugfs() which removes the directory but leaves a dangling pointer. If the component is later bound again, but _cs35l56_component_probe() fails early (for example, if the init_completion times out), this new error path will call cs35l56_component_remove(). This causes cs35l56_remove_cal_debugfs() to be called again with the dangling cs35l56_base->debugfs pointer from the previous lifecycle, resulting in a use-after-free in debugfs_remove_recursive(). Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration") Reported-by: sashiko Link: https://sashiko.dev/#/patchset/20260609120738.284770-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260610093432.557375-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c0c2c02507f24aebd250f4fdd373cdab04feeec0 Author: Richard Fitzgerald Date: Wed Jun 10 10:34:30 2026 +0100 ASoC: cs35l56: Fix missing calls to wm_adsp2_remove() [ Upstream commit 85f7bf03632bfcdd6cedfb3945b7e387d9487d73 ] Call wm_adsp2_remove() in cs35l56_remove() and the error path of cs35l56_common_probe(). Depends on commit 7d3fb78b5503 ("ASoC: wm_adsp: Fix NULL dereference when removing firmware controls"). The call to wm_halo_init() during driver probe should be paired with a call to wm_adsp2_remove() but this was missing. The consequence would be a memory leak of the control lists in the cs_dsp driver. Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260610093432.557375-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8bdd1032038e1730b748bf68c1fd5d38151959b5 Author: Christoph Hellwig Date: Wed Jun 10 07:06:42 2026 +0200 iomap: pass the correct len to fserror_report_io in __iomap_write_begin [ Upstream commit de654d66ff30e75d9308fd4d4f1627addef7923e ] len is size of the (larger) write request, plen is the range for which the read failed here. Fixes: a9d573ee88af ("iomap: report file I/O errors to the VFS") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260610050642.1906695-1-hch@lst.de Reviewed-by: "Darrick J. Wong" Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit c6c7eae5de798442987619434171ac886035d57c Author: Srujana Challa Date: Tue Feb 24 15:22:26 2026 +0530 vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler [ Upstream commit 0d21a1d6375a05274291e32c1ab7cd57dbb69513 ] Look up the IRQ index in oct_hw->irqs instead of assuming irq - irqs[0]. This supports non-contiguous IRQ numbers and avoids incorrect ring indexing when irqs[0] is not the base. Fixes: 26f8ce06af64 ("vdpa/octeon_ep: enable support for multiple interrupts per device") Signed-off-by: Srujana Challa Signed-off-by: Michael S. Tsirkin Message-ID: <20260224095226.1001151-5-schalla@marvell.com> Signed-off-by: Sasha Levin commit beae8aa57c8e61919f88d50134ea8c83e4dc35c2 Author: Srujana Challa Date: Tue Feb 24 15:22:23 2026 +0530 vdpa/octeon_ep: Fix PF->VF mailbox data address calculation [ Upstream commit 74dc530f4c505d61f0f3620e59fe56c325ae3437 ] The mailbox address was computed assuming 1 ring per VF. Read the actual rings-per-VF from OCTEP_EPF_RINFO and use it when calculating OCTEP_PF_MBOX_DATA offsets, fixing VF initialization when rings per VF > 1. Fixes: 8b6c724cdab8 ("virtio: vdpa: vDPA driver for Marvell OCTEON DPU devices") Signed-off-by: Srujana Challa Signed-off-by: Michael S. Tsirkin Message-ID: <20260224095226.1001151-2-schalla@marvell.com> Signed-off-by: Sasha Levin commit 7dd28904c42ee3b0728c0692dd3332c2c83e8f33 Author: Arnd Bergmann Date: Fri Feb 13 16:40:46 2026 +0100 vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO [ Upstream commit 455a2a1af92651764e9eb42cec0d95ac142afc28 ] These two ioctls are incompatible on 32-bit x86 userspace, because the data structures are shorter than they are on 64-bit. Add a proper .compat_ioctl handler for x86 that reads the structures with the smaller padding before calling the internal handlers. On all other architectures, CONFIG_COMPAT_FOR_U64_ALIGNMENT is disabled and no special handling is required. Fixes: ad146355bfad ("vduse: Support querying information of IOVA regions") Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Acked-by: Eugenio Pérez Signed-off-by: Arnd Bergmann Signed-off-by: Michael S. Tsirkin Message-ID: <20260213154051.4172275-1-arnd@kernel.org> Signed-off-by: Sasha Levin commit 068bdabc39a35d367af4a5755eff883bde7b5ed6 Author: longlong yan Date: Fri Jun 5 10:14:45 2026 +0800 tools/virtio: check mmap return value in vringh_test [ Upstream commit ec6177dfe98b9be1c3ede6c0dfe4394ea2a76959 ] In parallel_test(), the return values of mmap() for both host_map and guest_map are not checked against MAP_FAILED. If mmap() fails, the subsequent code will dereference the invalid pointer, leading to a segmentation fault. Add MAP_FAILED checks after both mmap() calls, using err() to report the error and exit, consistent with the existing error handling style in this file (e.g., the open() call on line 149). Fixes: 1515c5ce26ae ("tools/virtio: add vring_test.") Signed-off-by: longlong yan Signed-off-by: Michael S. Tsirkin Message-ID: <20260605021446.1611-1-yanlonglong@kylinos.cn> Signed-off-by: Sasha Levin commit c069437924663539a93a1e5afe90838d9ccee284 Author: Qing Ming Date: Mon Jun 1 18:43:00 2026 +0800 vhost/net: complete zerocopy ubufs only once [ Upstream commit 8f6898fe80794f2d7c3d38c1158c806e4074a1c4 ] vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs. Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support") Signed-off-by: Qing Ming Signed-off-by: Michael S. Tsirkin Message-ID: <20260601104300.197210-1-a0yami@mailbox.org> Signed-off-by: Sasha Levin commit 911fc274a65185ac994718ce2cc90edaec1e479a Author: Zhang Tianci Date: Thu Feb 26 19:55:49 2026 +0800 vduse: Requeue failed read to send_list head [ Upstream commit 373ec43ded742b2f3aecf14731ffe1a57f438f38 ] When copy_to_iter() fails in vduse_dev_read_iter(), put the message back at the head of send_list to preserve FIFO ordering and retry the oldest pending request first. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Reported-by: Michael S. Tsirkin Suggested-by: Xie Yongji Signed-off-by: Zhang Tianci Reviewed-by: Xie Yongji Acked-by: Jason Wang Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260226115550.1814-2-zhangtianci.1997@bytedance.com> Signed-off-by: Sasha Levin commit d308261f2fe0b462cf7427bcb4521ca3fe9a92f6 Author: Filip Hejsek Date: Mon Feb 23 18:37:02 2026 +0100 virtio_console: read size from config space during device init [ Upstream commit b3592a32b34f37874dc94aa1a0d15c4334ed86ca ] Previously, the size was only read upon receiving the config interrupt. This interrupt is sent when the size changes. However, we also need to read the initial size. Also make sure to only read the size from config if F_SIZE is enabled. Fixes: 9778829cffd4 ("virtio: console: Store each console's size in the console structure") Signed-off-by: Filip Hejsek Signed-off-by: Michael S. Tsirkin Message-ID: <20260223-virtio-console-fix-v1-1-0cf08303b428@gmail.com> Signed-off-by: Sasha Levin commit aebebd1e9d70b650fc9e877082e0134edcf511da Author: Jia Jia Date: Thu May 7 20:08:01 2026 +0800 virtio: rtc: tear down old virtqueues before restore [ Upstream commit 548d2208455f14e6121404c6e30e997bfe0cd264 ] virtio_device_restore() resets the device and restores the negotiated features before calling ->restore(). viortc_freeze() intentionally leaves the existing virtqueues in place so the alarm queue can still wake the system, but viortc_restore() immediately calls viortc_init_vqs() without first deleting those old queues. If virtqueue reinitialization fails on virtio-pci, the transport error path can run vp_del_vqs() against a newly allocated vp_dev->vqs array while vdev->vqs still contains the old virtqueues. vp_del_vqs() then looks up queue state through the new array and can dereference a NULL info pointer in vp_del_vq(), crashing the guest kernel during restore. This can also happen during a non-faulty reinitialization, when one of the vp_find_vqs_msix() attempts is unsuccessful before a later attempt would succeed. Delete the stale virtqueues before rebuilding them. If restore fails before virtio_device_ready(), reuse the remove path to stop the device. Once the device is ready, return errors directly instead of deleting the virtqueues again. Fixes: 0623c7592768 ("virtio_rtc: Add module and driver core") Signed-off-by: Jia Jia Reviewed-by: Peter Hilber Signed-off-by: Michael S. Tsirkin Message-ID: <20260507120801.3677552-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin commit 32ac9097aa2463fcfc12f61cc4a9ebc3579cba7d Author: Qihang Tang Date: Fri May 8 15:58:21 2026 +0800 vhost/vdpa: validate virtqueue index in mmap and fault paths [ Upstream commit 929e4f044621c8cc30b612fb74e1410bef09e41b ] vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS. Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Signed-off-by: Qihang Tang Signed-off-by: Michael S. Tsirkin Message-ID: <20260508075821.92656-1-q.h.hack.winter@gmail.com> Signed-off-by: Sasha Levin commit 79e12c891940b0c4c75881b7fd82a8cbb8ac97be Author: Qihang Tang Date: Fri May 8 17:46:59 2026 +0800 vduse: hold vduse_lock across IDR lookup in open path [ Upstream commit e440e077748939839d9f76e24383b76b785f80ce ] vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Signed-off-by: Qihang Tang Signed-off-by: Michael S. Tsirkin Message-ID: <20260508094659.94647-1-q.h.hack.winter@gmail.com> Signed-off-by: Sasha Levin commit 72202c72c3fca6d91fb189b650838f0dad7fc5a6 Author: Enric Balletbo i Serra Date: Thu May 14 13:14:17 2026 +0200 clocksource: move NXP timer selection to drivers/clocksource [ Upstream commit a9ac745bc320cbdc2ed3c851eb78f91f22ff975b ] The Kconfig logic for selecting the scheduler clocksource on NXP Vybrid (VF610) uses a `choice` block restricted to 32-bit ARM. This prevents 64-bit architectures, such as the NXP S32 family, from enabling the NXP Periodic Interrupt Timer (PIT) driver (CONFIG_NXP_PIT_TIMER). Relocate the NXP clocksource selection from arch/arm/mach-imx/Kconfig to drivers/clocksource/Kconfig. This allows the configuration to be shared across different architectures. Update the selection to include support for ARCH_S32 and add a "None" option restricted to ARCH_S32, since Vybrid lacks the ARM Architected Timer. The Vybrid Global Timer option is restricted to ARCH_MULTI_V7 SOC_VF610 platforms to prevent it from being visible on Cortex-M4 builds, which lack the ARM Global Timer hardware. Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support") Signed-off-by: Enric Balletbo i Serra Signed-off-by: Daniel Lezcano Reviewed-by: Frank Li Link: https://patch.msgid.link/20260514-fix-nxp-timer-v3-1-a3e68fdb505e@redhat.com Signed-off-by: Sasha Levin commit 9ea734e2cc0143d7429ab7dc0b20c85e5836183c Author: Justin Suess Date: Tue Jun 9 22:25:44 2026 +0200 bpf: Cancel special fields on map value recycle [ Upstream commit a3a81d247651218e47153f2d2afd7aee236726fd ] Map update and delete paths currently call bpf_obj_free_fields() when a value is being replaced or recycled. That makes field destruction depend on the context of the update/delete operation. For tracing programs this can include NMI context, where referenced kptr destructors, uptr unpinning, and graph root destruction are not generally safe. Introduce bpf_obj_cancel_fields() for the reusable-value path. It only performs NMI-safe cleanup for timer, workqueue, and task_work fields. Fields that need full destruction are left attached to the recycled value and are destroyed by the final cleanup path instead. Switch array and hashtab update/delete/recycle paths to this cancel helper. Keep bpf_obj_free_fields() for final map destruction and for bpf_mem_alloc destructors. Preallocated hashtabs do not have allocator destructors, so teardown continues to walk the normal and extra elements and fully destroy their fields. This deliberately relaxes the eager-free semantics of map update/delete for special fields. Programs that relied on a recycled map slot becoming empty immediately after update/delete were relying on behavior that cannot be implemented safely from every BPF execution context without offloading arbitrary destructors. There is a chance this change breaks programs making assumptions regarding the eager freeing of fields. If so, we can relax semantics to cancellation only when irqs_disabled() is true in the future. However, theoretically, map values that get reused eagerly already have weaker guarantees as parallel users can recreate freed fields before the new element becomes visible again. Fixes: 14a324f6a67e ("bpf: Wire up freeing of referenced kptr") Signed-off-by: Justin Suess Co-developed-by: Kumar Kartikeya Dwivedi Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260609202548.3571690-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6b86dc584bf3182504e7a12fce73b3b3184d9364 Author: Val Packett Date: Fri May 29 17:05:13 2026 -0300 ASoC: codecs: aw88261: fix incorrect masks for boost regs [ Upstream commit 79c053a1ff9d3ab31cefbc791e8d7816ba830491 ] The boost-related register fields used in aw88261_reg_force_set use the exact same definitions as the rest of the fields, where the mask must be inverted when passing it to regmap_update_bits, but they weren't inverted here. Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver") Signed-off-by: Val Packett Tested-by: Luca Weiss Link: https://patch.msgid.link/20260529200550.529719-7-val@packett.cool Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad88aa6cac75ef1c84c2e453e1bb787d1ff9384a Author: Ruoyu Wang Date: Tue Jun 9 13:26:47 2026 +0800 spi: meson-spifc: fix runtime PM leak on remove [ Upstream commit 606c0826bd90384a54571c0c5475ca41f50164ea ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error. meson_spifc_remove() uses it to resume the controller before disabling runtime PM, but never drops the usage counter again. Balance the get with pm_runtime_put_noidle() after disabling runtime PM, matching the teardown pattern used by other SPI controller drivers. Found by static analysis. I do not have hardware to test this. Fixes: c3e4bc5434d2 ("spi: meson: Add support for Amlogic Meson SPIFC") Signed-off-by: Ruoyu Wang Link: https://patch.msgid.link/20260609052647.5-1-ruoyuw560@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 686c2434f9f16b87aeed18d76cc562df9f2695ab Author: Chuck Lever Date: Thu May 14 16:56:07 2026 -0400 lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file() [ Upstream commit 6e4c62caecf792e8a15ad9bc7f371e57c17e3302 ] file_hash() digests the first LOCKD_FH_HASH_SIZE bytes of nfs_fh.data when bucketing nlm_files[], independent of fh.size. Commit 3de744ee4e45 ("lockd: Use xdrgen XDR functions for the NLMv4 TEST procedure") set .pc_argzero to zero for the converted procedures and moved file-handle population into nlm4svc_lookup_file(), which copies only xdr_lock->fh.len bytes into lock->fh.data. When an NLMv4 client presents a file handle shorter than LOCKD_FH_HASH_SIZE, bytes fh.len..31 retain whatever the argument buffer held from an earlier request. The same wire handle then hashes to different buckets across calls; nlm_lookup_file() misses the existing nlm_file entry, and lock-state lookups fail. Zero only the tail bytes that file_hash() would otherwise consume. Handles of LOCKD_FH_HASH_SIZE or larger already populate every byte that file_hash() reads. Reported-by: Jeff Layton Closes: https://lore.kernel.org/r/5229a9746d723a3f830120c0b966510f75badfc2.camel@kernel.org Fixes: 3de744ee4e45 ("lockd: Use xdrgen XDR functions for the NLMv4 TEST procedure") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ae3178e73497693923f33d5d56cc5c4e37c51956 Author: Chuck Lever Date: Tue May 12 14:13:40 2026 -0400 lockd: Do not monitor when looking up the LOCK_MSG callback host [ Upstream commit b3d200166a35305ac77941845dcab99bb6badd76 ] A LOCK_MSG handler that fails to obtain a host returns rpc_system_err, which causes the dispatcher to send an RPC-level error rather than an NLM LOCK_RES denial. Before the xdrgen conversion, the outer host lookup was unmonitored, so an NSM upcall failure was reported back to the client through LOCK_RES with status nlm_lck_denied_nolocks generated by the inner helper. The xdrgen conversion replaced the unmonitored lookup with nlm4svc_lookup_host(..., true). When nsm_monitor() fails, the outer lookup now returns NULL, so the procedure short-circuits to rpc_system_err and __nlm4svc_proc_lock_msg() never runs. The client therefore receives no LOCK_RES, regressing the legacy behavior. The inner helper still performs a monitored lookup while building the LOCK_RES, so the outer call only needs an unmonitored host reference for the callback path. Pass false here to restore the previous semantics. Fixes: b2be4e28c23a ("lockd: Use xdrgen XDR functions for the NLMv4 LOCK_MSG procedure") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 6ed9b32130d6571329564491ec64b81fefa58e91 Author: Chuck Lever Date: Tue May 12 14:13:39 2026 -0400 lockd: Translate nlm__int__deadlock in __nlm4svc_proc_lock_msg() [ Upstream commit 2175ca75882e346c9d8741a2196693d70f635340 ] When nlmsvc_lock() detects a deadlock it returns the internal sentinel nlm__int__deadlock (30001), which version-specific handlers must translate to a wire-valid status before the reply is encoded. The xdrgen LOCK_MSG handler stores the sentinel unmodified in resp->status; the LOCK_RES callback then places 30001 on the v4 wire, where the client rejects the reply. Commit 9e0d0c619407 ("lockd: Introduce nlm__int__deadlock") established the translation boundary and updated the synchronous v4 path nlm4svc_do_lock(), but the xdrgen LOCK_MSG handler added later in commit b2be4e28c23a ("lockd: Use xdrgen XDR functions for the NLMv4 LOCK_MSG procedure") missed the corresponding remap. Apply the same translation in __nlm4svc_proc_lock_msg() so deadlock results are reported as nlm4_deadlock on LOCK_RES. Fixes: b2be4e28c23a ("lockd: Use xdrgen XDR functions for the NLMv4 LOCK_MSG procedure") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 710582532196094a921247f06242e20ca2a5302c Author: Chuck Lever Date: Tue May 12 14:13:36 2026 -0400 lockd: Stop warning on nlm__int__drop_reply in !V4 cast_status [ Upstream commit 5cca6056f2bae9be14566e0f7f6e351103a6aef3 ] cast_status folds internal lock-daemon sentinels into NLMv1/v3 wire status codes. The !CONFIG_LOCKD_V4 variant warns when an unrecognized status falls into the internal-sentinel range, gated by be32_to_cpu(status) >= 30000. nlm__int__drop_reply is defined as cpu_to_be32(30000), so it sits at the lower edge of that range and trips pr_warn_once ("lockd: unhandled internal status %u"). The status is returned unchanged so the reply is still dropped, but every dropped reply on a !CONFIG_LOCKD_V4 build emits a spurious warning. Compare against nlm__int__drop_reply directly so the warning still catches the genuinely unexpected sentinels deadlock, stale_fh, and failed (30001 through 30003) but excludes the legitimate dropped-reply marker. Fixes: d343fce148a4 ("[PATCH] knfsd: Allow lockd to drop replies as appropriate") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 8024028ef91616cf91cc669f2446a0406bc0ba19 Author: Chuck Lever Date: Sun Apr 19 14:53:00 2026 -0400 NFSD: Handle layout stid in nfsd4_drop_revoked_stid() [ Upstream commit 86b9898920a6d02b4149f4fef9efd77b8aa3b9ca ] nfsd4_drop_revoked_stid() has no SC_TYPE_LAYOUT case, so when a client sends FREE_STATEID for an admin-revoked layout stid, the default branch releases cl_lock and returns without unhashing or releasing the stid. The stid remains in the IDR and on the per-client list until the client is destroyed. Remove the layout stid from the per-client list and call nfs4_put_stid() to drop the creation reference. When the refcount reaches zero, nfsd4_free_layout_stateid() handles the remaining cleanup: cancelling the fence worker, removing from the per-file list, and freeing the slab object. Fixes: 1e33e1414bec ("nfsd: allow layout state to be admin-revoked.") Reviewed-by: Jeff Layton Tested-by: Dai Ngo Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 29a7ec9a53ffd6e17595fc8a41d19bbfd4d616e1 Author: Jason Gunthorpe Date: Fri Jun 5 08:53:35 2026 -0300 IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified [ Upstream commit bade9a3150d44ed20b8c6484c4c8a943b7289abb ] Sashiko noticed mlx4 was using whatever random access flags were provided when IB_MR_REREG_ACCESS is not used. Since IB_MR_REREG_TRANS needs access_flags it used the random ones which means it doesn't work sensibly if userspace provides only IB_MR_REREG_TRANS. Keep track of the current access_flag of the MR and use it if the user does not specify one. Also fixup a little confusion around mmr.access, it is the HW access flags so the convert_access() was missing. But nothing reads this by the time rereg_mr can happen. Fixes: 9376932d0c26 ("IB/mlx4_ib: Add support for user MR re-registration") Link: https://patch.msgid.link/r/0-v1-29ca7a402625+ddd6-mlx4_rereg_flags_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e9414bbe3974f511a18bc728e813f0883838ab4f Author: Cássio Gabriel Date: Tue Jun 9 09:03:56 2026 -0300 ASoC: sma1307: Fix uevent string leaks in fault worker [ Upstream commit a750ca72af72dde9744468fdca6eda0b698a1cfc ] sma1307_check_fault_worker() stores dynamically allocated uevent strings in envp[0]. Several fault conditions are checked in sequence, so a later fault can overwrite envp[0] before the final kfree() and leak the previous allocation. The same flow can leave an OT1 volume entry in envp[1] while envp[0] has been overwritten by a later non-OT1 fault, causing an inconsistent uevent payload. Use static STATUS strings and a stack buffer for the optional VOLUME entry. This removes the allocations from the worker and keeps VOLUME tied only to the OT1 events that produce it. Fixes: 576c57e6b4c1 ("ASoC: sma1307: Add driver for Iron Device SMA1307") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260609-asoc-sma1307-uevent-leak-v1-1-cd7f5b062ab7@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 28781aa2351faa4c5a426ea713eda6a0838c5159 Author: KhaiWenTan Date: Fri Apr 24 15:59:07 2026 +0800 igc: skip RX timestamp header for frame preemption verification [ Upstream commit 38b7a274cf84af9b1f4b602b8e2741565b81947b ] When RX hardware timestamping is enabled, a 16-byte inline timestamp header is added to the start of the packet buffer, causing FPE handshake verification to fail. Because an incorrect packet buffer is passed to igc_fpe_handle_mpacket(), the mem_is_zero() check inspects the timestamp metadata instead of the actual mPacket payload. As a result, valid Verify/Response mPackets can be missed when inline RX timestamps are present. Pass pktbuf + pkt_offset to igc_fpe_handle_mpacket() so it inspects the actual mPacket payload instead of the timestamp header. Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Co-developed-by: Faizal Rahim Signed-off-by: Faizal Rahim Signed-off-by: KhaiWenTan Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a2a224f5e344ccb1ec3693a0735822db9214e2ca Author: Larysa Zaremba Date: Mon May 18 13:15:04 2026 +0200 ixgbe: do not configure xps for XDP queues [ Upstream commit 7bd4355272de34c2e90e34b72c5613736d03c32b ] netif_set_xps_queue() should not be called for an XDP Tx queue, since such queues are not netdev-exposed. On systems with number of CPUs >=64, on E610 adapter, netdev is configured with maximum number queue pairs being 63 (due to MSI-X assignment), but configuring XDP results in 64 XDP queues. So, during XDP program load, when netif_set_xps_queue() is called for the last XDP queue, we get a WARNING with a call trace and KASAN report afterwards (if enabled). [ 2012.699800] WARNING: net/core/dev.c:2854 at __netif_set_xps_queue+0x116a/0x1e40, CPU#36: xdpsock/103668 [...] [ 2012.700029] RIP: 0010:__netif_set_xps_queue+0x116a/0x1e40 [ 2012.700035] Code: b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84 [ 2012.700040] RSP: 0018:ffff8882369aeb28 EFLAGS: 00010246 [ 2012.700046] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 2012.700050] RDX: 1ffff1111da3d891 RSI: ffff888120e34250 RDI: ffff8888ed1ec488 [ 2012.700054] RBP: ffff888913281560 R08: 0000000000000000 R09: ffff8888ed1ec000 [ 2012.700058] R10: ffff8888a2e83180 R11: 0000000000000000 R12: 0000000000007fa8 [ 2012.700061] R13: 000000000000003f R14: ffff888120e34854 R15: ffff8889132817c8 [ 2012.700065] FS: 00007fc8ea9ff740(0000) GS:ffff88884cefe000(0000) knlGS:0000000000000000 [ 2012.700069] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2012.700073] CR2: 00007f81c8000020 CR3: 00000002299f8006 CR4: 00000000007726f0 [ 2012.700077] PKRU: 55555554 [ 2012.700080] Call Trace: [ 2012.700084] [ 2012.700087] ? ktime_get+0x61/0x150 [ 2012.700097] ? usleep_range_state+0x133/0x1b0 [ 2012.700108] ? __pfx_usleep_range_state+0x10/0x10 [ 2012.700114] netif_set_xps_queue+0x31/0x50 [ 2012.700119] ixgbe_configure_tx_ring+0x472/0x920 [ixgbe] [...] [ 2012.700486] ixgbe_xdp+0x38f/0x750 [ixgbe] [...] [ 2012.701094] BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1ac5/0x1e40 [ 2012.701100] Write of size 4 at addr ffff88888d43cff8 by task xdpsock/103668 Skip XPS configuration for XDP Tx queues. Fixes: 33fdc82f0883 ("ixgbe: add support for XDP_TX action") Reviewed-by: Alexander Lobakin Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1641d058adfbd50cf95d54581ed5d142ee82c07f Author: Weiming Shi Date: Sat Jun 6 22:25:13 2026 -0700 btrfs: lzo: reject compressed segment that overflows the compressed input [ Upstream commit b0d27d43791b7a3057c3c4aedf9b4aa033d37c46 ] lzo_decompress_bio() validates each on-disk segment length seg_len only against the workspace cbuf size, not against the compressed input size (compressed_len, the total folio bytes of the bio). A crafted extent can carry a segment whose seg_len passes the cbuf check but runs past the end of the bio, so copy_compressed_segment() walks off the last folio: get_current_folio() then returns the NULL folio from bio_next_folio(), and with CONFIG_BTRFS_ASSERT disabled (default) folio_size(NULL) faults. BUG: KASAN: null-ptr-deref in lzo_decompress_bio (fs/btrfs/lzo.c:383) Read of size 8 at addr 0000000000000000 by task kworker/u8:1/29 Workqueue: btrfs-endio simple_end_io_work kasan_report (mm/kasan/report.c:590) lzo_decompress_bio (fs/btrfs/lzo.c:383) end_bbio_compressed_read (fs/btrfs/compression.c:1065) btrfs_bio_end_io (fs/btrfs/bio.c:135) btrfs_check_read_bio (fs/btrfs/bio.c:180 fs/btrfs/bio.c:285) simple_end_io_work process_one_work worker_thread Reject any segment whose payload would extend beyond compressed_len before copying it, treating it as corruption like the other on-disk validation failures in this function. Reported-by: Xiang Mei Fixes: a6e66e6f8c1b ("btrfs: rework lzo_decompress_bio() to make it subpage compatible") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Qu Wenruo Signed-off-by: Weiming Shi Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ea3452726ccb6bcaa732f43cc57bb928eca3dd59 Author: Filipe Manana Date: Tue May 26 14:44:30 2026 +0100 btrfs: fix deadlock cloning inline extent when using flushoncommit [ Upstream commit 532085d00eb54c074bdeae648b194765239f4d11 ] In commit b48c980b6a7e ("btrfs: fix deadlock between reflink and transaction commit when using flushoncommit") a deadlock was fixed between reflinks and transaction commits when the fs is mounted with the flushoncommit option. This happened when we had to copy an inline extent's data to the destination file. However the issue was fixed only for the case where the destination offset is 0, it missed the case when the offset is greater than zero. Fix this by ensuring we get i_size update whenever we copied an inline extent's data into the destination file. Syzbot reported this with the following trace: INFO: task kworker/u8:3:57 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:3 state:D stack:21600 pid:57 tgid:57 ppid:2 task_flags:0x4208160 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-129) Call Trace: context_switch kernel/sched/core.c:5402 [inline] __schedule+0x16f9/0x5500 kernel/sched/core.c:7204 __schedule_loop kernel/sched/core.c:7283 [inline] schedule+0x164/0x360 kernel/sched/core.c:7298 wait_extent_bit fs/btrfs/extent-io-tree.c:905 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:2008 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x440/0xc00 fs/btrfs/inode.c:7718 extent_writepage fs/btrfs/extent_io.c:1848 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2552 [inline] btrfs_writepages+0x12f3/0x2410 fs/btrfs/extent_io.c:2684 do_writepages+0x32e/0x550 mm/page-writeback.c:2571 __writeback_single_inode+0x133/0x10e0 fs/fs-writeback.c:1764 writeback_sb_inodes+0x97f/0x1980 fs/fs-writeback.c:2056 wb_writeback+0x445/0xb00 fs/fs-writeback.c:2241 wb_do_writeback fs/fs-writeback.c:2388 [inline] wb_workfn+0x3fd/0xf20 fs/fs-writeback.c:2428 process_one_work+0x98b/0x1630 kernel/workqueue.c:3318 process_scheduled_works kernel/workqueue.c:3401 [inline] worker_thread+0xb49/0x1140 kernel/workqueue.c:3482 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 INFO: task syz.0.145:8523 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.0.145 state:D stack:22752 pid:8523 tgid:8522 ppid:5850 task_flags:0x400140 flags:0x00080002 Call Trace: context_switch kernel/sched/core.c:5402 [inline] __schedule+0x16f9/0x5500 kernel/sched/core.c:7204 __schedule_loop kernel/sched/core.c:7283 [inline] schedule+0x164/0x360 kernel/sched/core.c:7298 wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c:227 __writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c:2847 try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c:2895 btrfs_start_delalloc_flush fs/btrfs/transaction.c:2182 [inline] btrfs_commit_transaction+0x813/0x2fc0 fs/btrfs/transaction.c:2371 btrfs_sync_file+0xdf4/0x1230 fs/btrfs/file.c:1822 generic_write_sync include/linux/fs.h:2663 [inline] btrfs_do_write_iter+0x6a9/0x840 fs/btrfs/file.c:1473 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x629/0xba0 fs/read_write.c:688 ksys_write+0x156/0x270 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5a0bdece59 RSP: 002b:00007f5a0b446028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5a0c065fa0 RCX: 00007f5a0bdece59 RDX: 000000000000029f RSI: 0000200000000200 RDI: 0000000000000004 RBP: 00007f5a0be82d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5a0c066038 R14: 00007f5a0c065fa0 R15: 00007ffe149206b8 INFO: task syz.0.145:8539 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.0.145 state:D stack:23704 pid:8539 tgid:8522 ppid:5850 task_flags:0x400140 flags:0x00080002 Call Trace: context_switch kernel/sched/core.c:5402 [inline] __schedule+0x16f9/0x5500 kernel/sched/core.c:7204 __schedule_loop kernel/sched/core.c:7283 [inline] schedule+0x164/0x360 kernel/sched/core.c:7298 wait_current_trans+0x39f/0x590 fs/btrfs/transaction.c:536 start_transaction+0xbd8/0x1820 fs/btrfs/transaction.c:716 clone_copy_inline_extent fs/btrfs/reflink.c:299 [inline] btrfs_clone+0x1316/0x2540 fs/btrfs/reflink.c:574 btrfs_clone_files+0x271/0x3f0 fs/btrfs/reflink.c:795 btrfs_remap_file_range+0x76b/0x1320 fs/btrfs/reflink.c:948 vfs_clone_file_range+0x435/0x7b0 fs/remap_range.c:403 ioctl_file_clone fs/ioctl.c:239 [inline] ioctl_file_clone_range fs/ioctl.c:257 [inline] do_vfs_ioctl+0xe15/0x1540 fs/ioctl.c:544 __do_sys_ioctl fs/ioctl.c:595 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5a0bdece59 RSP: 002b:00007f5a0b425028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f5a0c066090 RCX: 00007f5a0bdece59 RDX: 00002000000000c0 RSI: 000000004020940d RDI: 0000000000000004 RBP: 00007f5a0be82d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5a0c066128 R14: 00007f5a0c066090 R15: 00007ffe149206b8 Reported-by: syzbot+c7443384724bb0f9e913@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/6a150a09.820a0220.e7972.0006.GAE@google.com/ Fixes: 05a5a7621ce6 ("Btrfs: implement full reflink support for inline extents") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 70780885a617a6675e4ce26d6636389b60fe185e Author: Cen Zhang Date: Wed Apr 1 10:21:53 2026 +0800 btrfs: annotate lockless read of defrag_bytes in should_nocow() [ Upstream commit 89c0dc3de7a73e8aba5e9bfef543eee047a3d0d2 ] should_nocow() reads inode->defrag_bytes without holding inode->lock, while btrfs_set_delalloc_extent() and btrfs_clear_delalloc_extent() update it under that spinlock. This is a data race. The read is a quick check used to decide whether to fall back to COW for a NOCOW inode: if defrag_bytes is non-zero and the range is tagged EXTENT_DEFRAG, we force COW so that defragmentation can rewrite the extent. Reading a stale value is harmless because: - A missed increment may skip COW once, but the defrag pass will redo the extent later. - A stale non-zero may force an unnecessary COW, which is a minor efficiency loss, not a correctness issue. On 64-bit platforms an aligned u64 load is naturally atomic so tearing cannot happen. On 32-bit platforms u64 may tear, but we only test for zero vs non-zero, so the heuristic stays correct regardless. Use data_race() annotation. Fixes: 47059d930f0e ("Btrfs: make defragment work with nodatacow option") Signed-off-by: Cen Zhang [ Use data_race() instead of READ_ONCXE() ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 68747085ea2a7745efcab089862da2fb76462bc8 Author: Johannes Thumshirn Date: Fri May 22 11:22:12 2026 +0200 btrfs: zoned: always set max_active_zones for zoned devices [ Upstream commit 21a3533b99b8a53a026cc9f5041b10795c1f3ae8 ] When a block device does not report a maximum number of open or active zones, currently assign BTRFS_DEFAULT_MAX_ACTIVE_ZONES (128) to the internal limit, if the device has more than BTRFS_DEFAULT_MAX_ACTIVE_ZONES zones. But if the device has less than BTRFS_DEFAULT_MAX_ACTIVE_ZONES the internal max_active_zones limit will stay at 0, even if the device has zone resource limits. Furthermore, if the device has a total number of zones that is less than BTRFS_DEFAULT_MAX_ACTIVE_ZONE, max_active_zones should be set to at most the number of zones. Also move the max_active_zone calculation and setting into a dedicated helper, to shrink btrfs_get_dev_zone_info(). Fixes: 04147d8394e8 ("btrfs: zoned: limit active zones to max_open_zones") Reviewed-by: Damien Le Moal Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d0f74832ba65985ee3235995d22fc249ff3710bb Author: Matthew Wilcox (Oracle) Date: Fri May 22 19:14:07 2026 +0100 Revert "btrfs: fix the file offset calculation inside btrfs_decompress_buf2page()" [ Upstream commit 0279bed34c22dd5ebff12e5af8ef940de93c5523 ] It seems that af566bdaff54 was tested against a tree which did not contain commit 12851bd921d4 ("fs: Turn page_offset() into a wrapper around folio_pos()). Unfortunately it has a bug of its own; on 32-bit systems, shifting by PAGE_SHIFT will overflow on files larger than 4GiB. Since page_offset() is now fixed, just revert af566bdaff54. Fixes: af566bdaff54 (btrfs: fix the file offset calculation inside btrfs_decompress_buf2page()) Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Qu Wenruo Reviewed-by: Boris Burkov Tested-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f84dbbaa988e1344634a20ddf6c7d51a99f12477 Author: Johannes Thumshirn Date: Fri May 22 11:02:47 2026 +0200 btrfs: zoned: fix deadlock waiting for ticket during data relocation [ Upstream commit 814c3b4ea357297c507158bceb07bcdc5fbe9808 ] When performing data relocation on a zoned filesystem, BTRFS can deadlock in handle_reserve_tickets(). The relocation process is waiting on a space reservation ticket that can never be fulfilled, because the relocation itself is the operation responsible for freeing up that space. Fix this by introducing a new flush state, BTRFS_RESERVE_FLUSH_ZONED_RELOCATION, specifically for data chunk allocation during zoned relocation. Like BTRFS_RESERVE_FLUSH_FREE_SPACE_INODE, this state uses priority_reclaim_data_space() instead of the normal flushing path, which avoids re-entering the relocation code and breaking the deadlock cycle. In btrfs_alloc_data_chunk_ondemand(), select this new flush state when the inode belongs to a data relocation root on a zoned filesystem. Fixes: e2a7fd22378f ("btrfs: zoned: add zone reclaim flush state for DATA space_info") Reviewed-by: Boris Burkov Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f3aa5ceea27ac613a56715159a1c19e429063ec0 Author: Johannes Thumshirn Date: Fri May 22 11:02:46 2026 +0200 btrfs: zoned: don't account data relocation space-info in statfs free space [ Upstream commit 52416a27aabc43eab3792fd0ca9f5dabeab58f31 ] Don't account the free space in a data relocation space-info sub-group as usable free space in statfs. This is misleading as no user allocations can be made in this space-info sub-group. It is only a target for relocation. Fixes: f92ee31e031c ("btrfs: introduce btrfs_space_info sub-group") Reviewed-by: Boris Burkov Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e19456097758a0744624bdc8363d38ea3b75a2f3 Author: Yuho Choi Date: Mon Jun 8 13:07:48 2026 -0400 PM: QoS: Fix misc device registration unwind [ Upstream commit 51a7c560cffdd3653ac2b930d01410569b23b23e ] cpu_latency_qos_init() registers cpu_dma_latency first and, when CONFIG_PM_QOS_CPU_SYSTEM_WAKEUP is enabled, registers cpu_wakeup_latency afterwards. The second registration overwrites the first return value. As a result, a failure to register cpu_dma_latency can be masked if the second registration succeeds. Conversely, if cpu_dma_latency succeeds and cpu_wakeup_latency fails, the function returns an error while leaving the first misc device registered. Return immediately on the first registration failure and deregister cpu_dma_latency if the second registration fails. Fixes: a4e6512a79d8 ("PM: QoS: Introduce a CPU system wakeup QoS limit") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260608170748.82273-1-dbgh9129@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5287b34dfbec273ed5a895108d1ef2221fde1491 Author: Nikita Zhandarovich Date: Fri May 29 17:18:36 2026 +0300 hwmon: (it87) Clamp negative values to zero in set_fan() [ Upstream commit 7f8581c70a3bd50a932d3d2d253e99c5ec3eda74 ] set_fan() parses user input with kstrtol() and passes the resulting value to FAN16_TO_REG() on chips with 16-bit fan support. Negative fan speeds are not meaningful and should be rejected before conversion. Worst scenario, one may be able to abuse undefined behaviour of signed overflow to possibly induce rpm * 2 == 0 in FAN16_TO_REG(), thus causing a division by zero. Instead, clamp val < 0 to zero and keep the conversion in its valid input domain, avoiding unsafe arithmetic in the register conversion path. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 17d648bf5786 ("it87: Add support for the IT8716F") Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20260529141839.1639287-1-n.zhandarovich@fintech.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 458c679c228b15476c5856af303301dfea2b954b Author: Jeff Layton Date: Thu Jan 29 16:47:43 2026 -0500 vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS [ Upstream commit c5d6cac28646b0d5d81ef632be748ae93c1f36c7 ] Commit e1c5ae59c0f2 ("fs: don't allow non-init s_user_ns for filesystems without FS_USERNS_MOUNT") prevents the mount of any filesystem inside a container that doesn't have FS_USERNS_MOUNT set. This broke NFS mounts in our containerized environment. We have a daemon somewhat like systemd-mountfsd running in the init_ns. A process does a fsopen() inside the container and passes it to the daemon via unix socket. The daemon then vets that the request is for an allowed NFS server and performs the mount. This now fails because the fc->user_ns is set to the value in the container and NFS doesn't set FS_USERNS_MOUNT. We don't want to add FS_USERNS_MOUNT to NFS since that would allow the container to mount any NFS server (even malicious ones). Add a new FS_USERNS_DELEGATABLE flag, and enable it on NFS. Fixes: e1c5ae59c0f2 ("fs: don't allow non-init s_user_ns for filesystems without FS_USERNS_MOUNT") Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260129-twmount-v1-1-4874ed2a15c4@kernel.org Acked-by: Anna Schumaker Reviewed-by: Alexander Mikhalitsyn Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 4d47898f150fd73cec3d92f0f8cb739fe5111fe8 Author: Sumit Gupta Date: Wed May 27 19:31:25 2026 +0530 memory: tegra186-emc: stop borrowing MC aggregate hook for EMC [ Upstream commit 2e05f3d6005d9aa3e2e423d2471f290d9ccbe3d2 ] tegra186_emc_interconnect_init() copies the MC's ICC aggregate hook into the EMC provider. That hook (tegra234_mc_icc_aggregate / tegra264_mc_icc_aggregate) uses container_of() to recover 'mc', which is only valid when the icc_provider is embedded in struct tegra_mc. For an EMC node the provider is embedded in struct tegra186_emc, so 'mc' points into unrelated memory. This stayed harmless until commit faafd6ca7e6e ("memory: tegra: make icc_set_bw return zero if BWMGR not supported") added an unconditional read of mc->bwmgr_mrq_supported at the top of the hook. UBSAN catches the stray load on every EMC aggregation: UBSAN: invalid-load in drivers/memory/tegra/tegra234.c:1104:9 load of value 112 is not a valid value for type '_Bool' No functional impact in practice, since the hook's only other mc dereference (mc->num_channels) sits inside a TEGRA_ICC_MC_CPU_CLUSTER* branch that EMC nodes never enter. Fix this by setting the EMC provider's aggregate hook to icc_std_aggregate, instead of borrowing the MC's hook. The MC providers continue using their own aggregate hooks, where container_of() correctly resolves to struct tegra_mc. Reported-by: Jon Hunter Fixes: 9a38cb27668e ("memory: tegra: Add interconnect support for DRAM scaling in Tegra234") Signed-off-by: Sumit Gupta Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://patch.msgid.link/20260527140127.49172-2-sumitg@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 48cf0f4c6581ec90104cec9c5bf794a8bf347e30 Author: David Laight Date: Mon Jun 8 13:42:42 2026 +0100 fbdev: sm501fb: Fix buffer errors in OF binding code [ Upstream commit d8421e09382cfe0bd2a044c8b0a822f64855dd4e ] The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, "mode", &len) is just written over either the static "640x480-16@60" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info. Fixes: 4295f9bf74a88 ("video, sm501: add OF binding to support SM501") Signed-off-by: David Laight Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 85c36b01a2efb5dd256c41eeddc1941ac0bddf6c Author: Helge Deller Date: Tue Jun 9 09:22:09 2026 +0200 fbdev/arm: Export acorndata_8x8 font symbol for bootloader [ Upstream commit 470ea955a18c76eeb10ca11ffcb2fe923bfc5515 ] The text display code used in the Risc PC kernel image decompression code uses arch/arm/boot/compressed/font.c, which includes lib/fonts/font_acorn_8x8.c, which further includes . Since commit 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size") contains inline functions that require __do_div64, which is not linked into the ARM kernel decompressor. This makes Risc PC zImages fail to build. Resolve this issue by defining the BOOTLOADER symbol and use it to avoid a static declaration of the acorndata_8x8 symbol. That way it can be referenced by the arm bootloader, and other static math functions and symbols (like __do_div64) stay static and don't get unneccesary included in the ARM kernel bootloader decompressor object file. Fixes: 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size") Reported-by: Ethan Nelson-Moore Reviewed-by: Thomas Zimmermann Cc: linux-arm-kernel@lists.infradead.org Cc: Russell King Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 4abb91b6de01332548655b060078b5d2160d2afe Author: Wen Gong Date: Thu Jun 4 15:28:31 2026 +0530 wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported [ Upstream commit 63abe299b12b317dfee5bcd09037da4668a4431a ] When firmware reports NSS ratio support, SUPPORTS_VHT_EXT_NSS_BW is enabled in ath12k. However, IEEE80211_VHT_EXT_NSS_BW_CAPABLE must also be set to make the advertisement valid. According to IEEE Std 802.11-2024, Subclause 9.4.2.156.3 (Supported VHT-MCS and NSS Set subfields), the VHT Extended NSS BW Capable bit indicates whether a STA is capable of interpreting the Extended NSS BW Support subfield of the VHT capabilities information field. Advertising extended NSS BW support without setting this capability bit is therefore invalid. Without this change, mac80211 detects the inconsistency and logs: ieee80211 phy0: copying sband (band 1) due to VHT EXT NSS BW flag This indicates that mac80211 implicitly aligns IEEE80211_VHT_EXT_NSS_BW_CAPABLE during ieee80211_register_hw(). Explicitly setting the bit in ath12k avoids this fixup and ensures capabilities are advertised correctly by the driver. This change follows the same approach as the existing ath11k fix. https://lore.kernel.org/all/20211013073704.15888-1-wgong@codeaurora.org/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 18ab9d038fad ("wifi: ath12k: add support for 160 MHz bandwidth") Signed-off-by: Wen Gong Signed-off-by: Maharaja Kennadyrajan Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260604095831.2674298-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1280e828e3c3d7de5aadc816d5fc6a8408ebfcce Author: Baochen Qiang Date: Tue Jun 9 10:10:47 2026 +0800 wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits [ Upstream commit fdea4d44e4b9c3f7021c85f8cd766e84e224472d ] On WCN7850, after the following sequence: 1. load ath12k and connect to a non-MLO AP 2. disconnect and connect to an MLO AP 3. disconnect and reconnect to the non-MLO AP the third connection always fails with a 4-Way handshake timeout. The supplicant transmits message 2 of 4 four times in response to AP retries of message 1, but the AP never sees any of them. ath12k_dp_vdev_tx_attach() composes dp_link_vif->tcl_metadata using |=, but dp_link_vif is embedded in struct ath12k_dp_vif and its slots are reused across vif/peer teardown and setup. Since tcl_metadata is never cleared on detach, vdev_id bits from a previous attach remain set when the same link slot is reused with a different vdev_id. In this specific issue, the same link slot is used for vdev_id 0, then vdev_id 1, then vdev_id 0 again, the OR yields tcl_metadata == 0x9, which encodes vdev_id 1 in the HTT_TCL_META_DATA_VDEV_ID field even though ti.vdev_id is 0. Firmware then routes the EAPOL frame to the wrong vdev and the AP never receives message 2. Use plain assignment instead of |= so the field is fully recomputed from the current arvif on every attach. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: af66c7640cf9 ("wifi: ath12k: Refactor ath12k_vif structure") Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260609-ath12k-fix-eapol-tcl-metadata-v1-1-d47e6f90d4ee@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9e5c672ab9c91357550f6f5fd0d458cc28110fe2 Author: Sergio Paracuellos Date: Tue Jun 9 05:11:18 2026 +0200 gpio: mt7621: fix interrupt banks mapping on gpio chips [ Upstream commit a46f2e5720f5670feda145709d1f0d20be5c7263 ] The GPIO controller's registers are organized as sets of eight 32-bit registers with each set controlling a bank of up to 32 pins. A single interrupt is shared for all of the banks handled by the controller. The driver implements this using three gpio chip instances every one with its own irq chip. Every single pin can generate interrupts having a total of 96 possible interrupts here. It looks like there is a problem with interrupts being properly mapped to the gpio bank using this solution. This problem report is in the following lore's link [0]. Device tree is using two cells for this, so only the interrupt pin and the interrupt type are described there. Changing to have three cells to setup also the bank and implement 'of_node_instance_match()' would also work but this would be an ABI breakage and also a bit incoherent since gpios itself are also using two cells and properly mapped in desired bank using through its pin number on 'of_xlate()'. That said, register a linear IRQ domain of the total of 96 interrupts shared with the three gpio chip instances so the bank and the interrupt is properly decoded and devices using gpio IRQs properly work. [0]: https://lore.kernel.org/linux-gpio/CAAMcf8C_A9dJ_v4QRKtb9eGNOpJ7BZNOGsFP4i2WFOZxOVBPnQ@mail.gmail.com/T/#u Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621") Co-developed-by: Vicente Bergas Signed-off-by: Vicente Bergas Tested-by: Vicente Bergas Signed-off-by: Sergio Paracuellos Link: https://patch.msgid.link/20260609031118.2275735-1-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 79a1d86b83cf895d73c0cdebbe8273ece79428af Author: Takashi Iwai Date: Tue Jun 9 09:49:04 2026 +0200 ALSA: aloop: Drop superfluous break [ Upstream commit 123fd13f35ccaf7d2b98f5a8cc6c8a3de378568d ] At converting the spinlock to guard(), a break statement was put in the scoped_guard block in loopback_jiffies_timer_function(), but it's obviously superfluous (although it's harmless). Better to drop it for avoiding confusion. Fixes: 1ef2cb6b29c2 ("ALSA: aloop: Use guard() for spin locks") Link: https://patch.msgid.link/20260609074907.726593-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9faa6b69ad73f03c7bde53e07d75a28822dc9a1a Author: Filipe Manana Date: Thu May 21 15:19:37 2026 +0100 btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() [ Upstream commit 486f8298b6188ff11ef1f4be7f1d5d2e4d1b1fae ] In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 ("btrfs: refactor __btrfs_run_delayed_refs loop") but were unintentionally lost afterwards. Reported-by: Dan Carpenter Link: https://lore.kernel.org/linux-btrfs/ag8ARRwykv8bpJ87@stanley.mountain/ Fixes: 0110a4c43451 ("btrfs: refactor __btrfs_run_delayed_refs loop") Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b13342aa835685cdec5f216fe7c4df2f59a48016 Author: Ryder Lee Date: Fri Jun 5 04:33:06 2026 -0700 wifi: mt76: mt7996: fix potential tx_retries underflow [ Upstream commit 4d8bba99d645bcb46a442b18eb42402610cba03a ] When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: 2461599f835e ("wifi: mt76: mt7996: get tx_retries and tx_failed from txfree") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/20260605113306.3485554-4-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e17c4412754eac348ff1205fa337ec7ffc21f43d Author: Ryder Lee Date: Fri Jun 5 04:33:05 2026 -0700 wifi: mt76: mt7925: fix potential tx_retries underflow [ Upstream commit 1e1fd84571e62a2961cea44c053340ec5c99b2cb ] When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/20260605113306.3485554-3-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e13959152ad85b656e336af9be695c283cce3462 Author: Ryder Lee Date: Fri Jun 5 04:33:04 2026 -0700 wifi: mt76: mt7921: fix potential tx_retries underflow [ Upstream commit 3c5671ed81b1fff97fa868dae771690599db94f7 ] When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: 9aecfa754c7f ("wifi: mt76: mt7921e: report tx retries/failed counts in tx free event") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/20260605113306.3485554-2-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c990141f11dd255cabed5da2c5a4a249e09d4bc3 Author: Ryder Lee Date: Fri Jun 5 04:33:03 2026 -0700 wifi: mt76: mt7915: fix potential tx_retries underflow [ Upstream commit 05e72b6167970043348bfbe8f72a3b67a38a9f1c ] When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: 943e4fb96e6f ("wifi: mt76: mt7915: report tx retries/failed counts for non-WED path") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/20260605113306.3485554-1-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2a2830ff8febe2332001e901558cca12226a4e71 Author: Bjoern A. Zeeb Date: Tue Mar 31 22:05:47 2026 +0000 wifi: mt76: fix argument to ieee80211_is_first_frag() [ Upstream commit 5832743279da8c6ae72f715bad2f7141eca6f4b8 ] ieee80211_is_first_frag() operates on the seq_ctrl not the frame_control header field. Pass the correct one in; otherwise the results may vary. Sponsored by: The FreeBSD Foundation Fixes: 30ce7f4456ae4 ("mt76: validate rx CCMP PN") Link: https://cgit.freebsd.org/src/commit/sys/contrib/dev/mediatek/mt76/mac80211.c?id=c67fd35e58c6ee1e19877a7fe5998885683abedc Signed-off-by: Bjoern A. Zeeb Link: https://patch.msgid.link/83s4psnr-popo-8789-757o-npr2n9n7rs2o@SerrOFQ.bet Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 66d36e9bb4367fac6661b4804c765460cbf0e767 Author: Dylan Eskew Date: Wed Apr 8 07:50:58 2026 -0700 wifi: mt76: mt7996: limit work in set_bitrate_mask [ Upstream commit 5fd3385505600934f5faa9635e5b30fa38e548b9 ] Calls to mt7996_set_bitrate_mask() would propagate work for all stations on the ieee80211_hw regardless of the vif specified in the call. To prevent unnecessary work in FW, limit setting the sta_rate to only the specified vif in mt7996_sta_rate_ctrl_update(). Fixes: afff4325548f0 ("wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback") Signed-off-by: Dylan Eskew Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260408145057.2356878-2-dylan.eskew@candelatech.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0df68463abdaf655d8ea493d68aea785a6093d2a Author: Lorenzo Bianconi Date: Fri May 22 09:24:52 2026 +0200 wifi: mt76: mt7996: remove redundant pdev->bus check in probe [ Upstream commit 6b294950eaac246e6b0f42d74aa643ff36384c6e ] Drop the unnecessary pdev->bus NULL check in mt7996_pci_probe() since the pointer is already dereferenced earlier in mt76_pci_disable_aspm(), making the check dead code. Silences the related Smatch warning. Fixes: 377aa17d2aed ("wifi: mt76: mt7996: Add NPU offload support to MT7996 driver") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260522-mt7996-pdev-bus-fix-v1-1-c91716484365@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e6abc3325ff25c5637e078b61fa7e55cabd2c83b Author: Lorenzo Bianconi Date: Sun May 31 10:55:04 2026 +0200 wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add() [ Upstream commit 729c83a3330c0a56662cd0d8e40db96d41c00a54 ] mt76_tx_status_skb_add() zeroes the mt76_tx_cb struct stored at info->status.status_driver_data via memset(). Since info->control and info->status are members of the same union in ieee80211_tx_info, this overwrites info->control.flags. In mt7996_tx_prepare_skb(), mt76_tx_status_skb_add() is called before mt7996_mac_write_txwi(), which re-reads info->control.flags to extract IEEE80211_TX_CTRL_MLO_LINK. Because the field has been zeroed, the link_id always resolves to 0 for frames using global_wcid, leading to incorrect TXWI configuration. Fix this by passing link_id as an explicit parameter to mt7996_mac_write_txwi(). In mt7996_tx_prepare_skb(), the link_id is already extracted from info->control.flags before the destructive mt76_tx_status_skb_add() call. For the beacon and inband discovery callers in mcu.c, use link_conf->link_id directly. Fixes: f0b0b239b8f36 ("wifi: mt76: mt7996: rework mt7996_mac_write_txwi() for MLO support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260531-mt76_tx_status_skb_add-overwrite-fix-v2-1-b73c4b4a9798@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 63e6151b9791b31877a88ff62806e7c407683955 Author: Lorenzo Bianconi Date: Sun May 31 11:38:57 2026 +0200 wifi: mt76: mt7996: Fix possible NULL pointer dereference in mt7996_mac_write_txwi_80211() [ Upstream commit 61370e6674b5253de5686813ceeceebc35a7d3e5 ] For injected frames (e.g. via radiotap), mac80211 can pass info->control.vif = NULL, as explicitly noted in struct ieee80211_tx_info. Check vif pointer before executing ieee80211_vif_is_mld() in mt7996_mac_write_txwi_80211 routine in order to avoid a possible NULL pointer dereference. Fixes: f0b0b239b8f36 ("wifi: mt76: mt7996: rework mt7996_mac_write_txwi() for MLO support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260531-mt7996_mac_write_txwi_80211-null-ptr-deref-v1-1-6dd38e1d3422@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fa0e9aa92a7bc97fc42014c5efaaf1278fa92723 Author: Lorenzo Bianconi Date: Sun May 31 11:10:59 2026 +0200 wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb() [ Upstream commit 831074096d0450308357271fc0ffd3f600a2487e ] If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine, mt7996 driver leaks an already allocated tx token. Fix the issue releasing the token in case of error. Fixes: 7ef0c7ad735b0 ("wifi: mt76: mt7996: Implement MLD address translation for EAPOL") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260531-mt7996_tx_prepare_skb-token-leack-v1-1-2b9c9f59ceb1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e8b214b6d6e1902025452db0a0af73dc9693e4ba Author: Aviel Zohar Date: Mon Apr 13 06:31:34 2026 +0300 wifi: mt76: mt7925: validate skb length in testmode query [ Upstream commit c7369a00860a0704461d440e7c3bf9b49bfdbaee ] In mt7925_tm_query(), the response skb from mt76_mcu_send_and_get_msg() is used in a memcpy without validating its length: memcpy(evt_resp, skb->data + 8, MT7925_EVT_RSP_LEN); where MT7925_EVT_RSP_LEN is 512. If the firmware returns a response shorter than 520 bytes (8 + 512), this reads beyond the skb data buffer. The over-read data is then returned to userspace via nla_put() in mt7925_testmode_dump(). Add a length check before the memcpy to ensure the skb contains sufficient data. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Aviel Zohar Link: https://patch.msgid.link/20260413033136.5417-2-avielzohar123@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3a42b17b655eb1ddd435c0bd84dba0748e69ee6f Author: Sean Wang Date: Sat Apr 25 09:46:48 2026 -0500 wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX [ Upstream commit a1152244702bb31b64650e5ca8308142286c0e4a ] mt792x_tx() rewrites addr1/addr2/addr3 by treating skb->data as an 802.11 header for MLD traffic. That is only valid for native 802.11 frames. Direct 802.3 TX can also reach this path with IEEE80211_TX_CTL_HW_80211_ENCAP set, where skb->data is not an 802.11 header. Skip the MLD header rewrite for HW-encap packets to avoid corrupting 802.3 frame contents. Fixes: ebb1406813c6 ("wifi: mt76: mt7925: add link handling to txwi") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260425144648.734030-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4992ec3019ead1047f87a91bf5ed00ae3a47debe Author: Sean Wang Date: Sat Apr 25 10:47:19 2026 -0500 wifi: mt76: mt7925: keep TX BA state in the primary WCID [ Upstream commit d3c854068bad22a25db6515f12784f64c663fed2 ] For MLO, the same TID can run over different links. Keeping TX BA state in a link WCID makes the state depend on which link starts aggregation first. Store it in the primary WCID instead, so the BA state stays stable across links. Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Tested-by: Yao Ting Hsieh Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260425154721.738101-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8703e294044f808425fca0b7c65220a4884c5ed7 Author: Javier Tia Date: Sat Apr 25 14:49:51 2026 -0500 wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links [ Upstream commit 9f1accf3069a0cd42c14ca6c7d44d5b17cc48a80 ] In the error path of mt7925_change_vif_links(), the free: label iterates over link_ids to clean up, but compares against `mconf` and `mlink` which hold stale values from the last loop iteration rather than the current link_id being freed. Use array-indexed access (mconfs[link_id] / mlinks[link_id]) to compare against the correct per-link pointers. Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links") Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Tested-by: 张旭涵 Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 93f3f9a9e955569ab7c3f02f0486d3aaf2314a56 Author: Lorenzo Bianconi Date: Sat Apr 18 20:04:16 2026 +0200 wifi: mt76: mt7996: Fix NULL pointer dereference in mt7996_init_tx_queues() [ Upstream commit 6794edb55b5f5ef834e03b0b241b1a8b725f82c0 ] When MT76_NPU and CONFIG_NET_MEDIATEK_SOC_WED are enabled and mt76 detects properly the Airoha NPU SoC, mt7996_init_tx_queues() will dereference a NULL WED pointer. Fix the issue by always passing the WED pointer from mt7996_dma_init(). Fixes: cd7951f242a7 ("wifi: mt76: mt7996: Integrate MT7990 dma configuration for NPU") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260418-mt7996-dma-init-npu-fix-v1-1-6b8dcffbcb57@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 82fe6fc1e6ad8358a680a4a98ec35d1625a69ef4 Author: Felix Fietkau Date: Tue Mar 24 15:49:04 2026 +0000 wifi: mt76: mt7996: add missing max_remain_on_channel_duration [ Upstream commit ac41612e0044fa29cf9bc45b6808dda6d87ac2da ] Having this unset breaks remain-on-channel and mgmt TX. Move setting it to mt76 core to keep it in one place. Fixes: 69d54ce7491d0 ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Link: https://patch.msgid.link/20260324154904.2555603-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 50e700ac0edce72dee5c3a9755865d9423696ac7 Author: Rajat Gupta Date: Wed May 6 21:35:31 2026 -0700 wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link [ Upstream commit 7fae097aa9a56c30febf539d72ef3773165d3aa3 ] mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree() after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents future RCU readers from obtaining the pointer -- it does not wait for existing readers that already hold it via rcu_dereference. The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer via rcu_dereference just before the NULL assignment, it will dereference freed memory after the kfree. struct mt76_vif_link already contains an rcu_head field that is unused at this free site -- a developer oversight, since the adjacent kfree_rcu_mightsleep call for rx_sc in the same function shows the pattern was understood. Replace kfree(mlink) with kfree_rcu(mlink, rcu_head). Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions") Signed-off-by: Rajat Gupta Link: https://patch.msgid.link/20260507043531.492-1-rajat.gupta@oss.qualcomm.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 79a307b2730e4b4e060cf3e19a6c21b87116ee78 Author: Hongling Zeng Date: Tue May 12 14:52:45 2026 +0800 wifi: mt76: mt7921: fix resource leak in probe error path [ Upstream commit 346dac35b1384af9338b34b6835e82e634ea4d2c ] When pcim_iomap_region() or devm_kmemdup() fail, the code returns directly without cleaning up previously allocated resources: - mt76_device allocated by mt76_alloc_device() - pci irq vectors allocated by pci_alloc_irq_vectors() Fix this by jumping to the existing error cleanup path instead of returning directly. Fixes: ee5bb35d2b83 ("wifi: mt76: mt7921: Replace deprecated PCI function") Fixes: 222606f43b58 ("wifi: mt76: mt7921: handle MT7902 irq_map quirk with mutable copy") Signed-off-by: Hongling Zeng Link: https://patch.msgid.link/20260512065245.46496-1-zenghongling@kylinos.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fd61b79406a83ed22e63ac36db2feae718c527f6 Author: Myeonghun Pak Date: Sun Apr 26 23:33:36 2026 +0900 wifi: mt76: mt7925: clean up DMA on probe failure [ Upstream commit 9629f31f505d74e76ac0d7a9492fd06c0316fc5d ] mt7925_pci_probe() initializes DMA before registering the device. If mt7925_register_device() fails, probe returns through err_free_irq without tearing down DMA state. That leaves the TX NAPI instance enabled and skips the DMA queue cleanup that the normal remove path performs through mt7925e_unregister_device(). Add a dedicated unwind label for failures after mt7925_dma_init() succeeds. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260426143728.41534-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b577efff47f7c18717546b777f5e10cd2092f2f9 Author: Krzysztof Kozlowski Date: Wed Jun 3 09:27:27 2026 +0200 ARM: configs: Drop duplicated CONFIG_EXT4_FS [ Upstream commit ae371a58117d30a496e3be27cce8d9d13acdd740 ] Remove redundant, duplicated CONFIG_EXT4_FS to fix warnings like: axm55xx_defconfig:198:warning: override: reassigning to symbol EXT4_FS Fixes: c065b6046b34 ("Use CONFIG_EXT4_FS instead of CONFIG_EXT3_FS in all of the defconfigs") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Richard Cheng Link: https://lore.kernel.org/r/20260603072726.19404-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 94911533a4b7b371df4d06f1a5c393042b9ba7bb Author: Hongyan Xia Date: Fri Jun 5 09:43:39 2026 +0000 sched/fair: Fix cpu_util runnable_avg arithmetic [ Upstream commit 29922fdfc2a4008d66418bedd0ebf5038fc54efa ] If we take runnable_avg in max(runnable_avg, util_avg) in cpu_util(), we should then add or subtract task runnable_avg, but the arithmetic below is still with task util_avg. This mixes runnable_avg with util_avg which is incorrect. Fix by always doing arithmetic with runnable_avg and only take max(runnable_avg, util_avg) at the last step. Fixes: 7d0583cf9ec7 ("sched/fair, cpufreq: Introduce 'runnable boosting'") Signed-off-by: Hongyan Xia Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://patch.msgid.link/20260605094318.37931-1-hongyan.xia@transsion.com Signed-off-by: Sasha Levin commit 274cd52fde330b74ae2a53e8864db89f9cb18509 Author: Wolfram Sang Date: Tue May 12 11:13:03 2026 +0200 hwspinlock: qcom: avoid uninitialized struct members [ Upstream commit 8752c396ce3b2136b3d4c906fe103f6efb6782d9 ] The reg_field is allocated on stack, so using the REG_FIELD macro will ensure that unused members do not have uninitialized values. Fixes: 19a0f61224d2 ("hwspinlock: qcom: Add support for Qualcomm HW Mutex block") Link: https://sashiko.dev/#/patchset/20260319105947.6237-1-wsa%2Brenesas%40sang-engineering.com Signed-off-by: Wolfram Sang Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260512091339.31085-2-wsa+renesas@sang-engineering.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fdd7c6490ec39ff59ffed60b4eff3644ccfff53c Author: Alexandru Gagniuc Date: Mon Dec 8 16:33:14 2025 -0600 remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset [ Upstream commit 6ad61d0acd41044a949e84f96a5f8e02284d350f ] The wcss_q6_bcr_reset used on QCS404, and wcss_q6_reset used on IPQ are the same. "BCR reset" is redundant, and likely a mistake. Use the documented "wcss_q6_reset" instead. Drop ".wcss_q6_reset_required" from the descriptor, since all targets now need it. This changes the bindings expectations, however, it actually fixes the driver to consume the intended ones (qcom,q6v5.txt), which lists "wcss_q6_reset" and *not* "wcss_q6_bcr_reset" Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Reviewed-by: Konrad Dybcio Signed-off-by: Alexandru Gagniuc Link: https://lore.kernel.org/r/20251208223315.3540680-1-mr.nuke.me@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3c853f7bd67db3df98ee3685180eab78f92b873f Author: Miguel Ojeda Date: Mon Jun 8 16:14:21 2026 +0200 rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary` [ Upstream commit 70a8d5ada9fabf4a34732b718f9c992195eed2ea ] When Clippy is skipped, `RUSTC` should be shown in `quiet` instead of `CLIPPY` to be accurate and to avoid confusion. Thus do so, matching what we do in `quiet_cmd_rustc_library`. Fixes: 7dbe46c0b11d ("rust: kbuild: add proc macro library support") Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260608141439.182634-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 55a44f5259e6a5f1d5b11cb0e19e943c9cc62280 Author: Hui Zhu Date: Fri May 29 09:41:30 2026 +0800 vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() [ Upstream commit c55dd3b46c1208d6d2ea737a8aefef4aa4c70cb8 ] find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash. Link: https://lore.kernel.org/20260529014130.671291-1-hui.zhu@linux.dev Fixes: 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings") Signed-off-by: Hui Zhu Reviewed-by: Dev Jain Reviewed-by: Uladzislau Rezki (Sony) Cc: Nicholas Piggin Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8346a7db76402108e280737ffb9e4e6891db4da7 Author: Hao Ge Date: Thu May 28 09:13:36 2026 +0800 lib/test_hmm: fix memory leak in dmirror_migrate_to_system() [ Upstream commit 8f7275c174bc5bcc8fc1bec8024e2b3e6fe17f46 ] Move the kvcalloc() calls after the early return checks to avoid leaking src_pfns and dst_pfns when end < start or mmget_not_zero() fails. Link: https://lore.kernel.org/20260528011336.20797-1-hao.ge@linux.dev Fixes: 775465fd26a3 ("lib/test_hmm: add zone device private THP test infrastructure") Signed-off-by: Hao Ge Reviewed-by: Alistair Popple Reported-by: Sashiko Reviewed-by: Balbir Singh Cc: Jason Gunthorpe Cc: Leon Romanovsky Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0507fcedbdcc87281ef8639c045fc9980363bbb6 Author: Jason Gunthorpe Date: Mon Jun 8 21:20:25 2026 -0300 iommufd: Destroy the pages content after detaching from dmabuf [ Upstream commit f2d70dbd3dcefa8e3c380beff9c31f5f033a4221 ] Sashiko points out this has gotten out of order, the mutex could still be in use through the dmabuf invalidation callbacks. Don't destroy any of the pages content until the dmabuf is fully detached. Fixes: 71db84a092c3 ("iommufd: Add DMABUF to iopt_pages") Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cc69d0332421fd2943b66dbe5e597bf4fd5af126 Author: Ankit Soni Date: Tue May 26 11:10:34 2026 +0000 iommufd: Take dma_resv lock before dma_buf_unpin() in release path [ Upstream commit e745cd2c749e557c14a15ac931761c3f58c24489 ] dma_buf_unpin() requires the caller to hold the exporter's dma_resv lock: void dma_buf_unpin(struct dma_buf_attachment *attach) { ... dma_resv_assert_held(dmabuf->resv); ... } iopt_release_pages() calls dma_buf_unpin() without taking that lock, so every iommufd_ioas_destroy()/iommufd_ioas_unmap() that releases the last reference on a DMABUF-backed iopt_pages triggers a WARN. This was hit while running tools/testing/selftests/iommu/iommufd: WARNING: drivers/dma-buf/dma-buf.c:1137 at dma_buf_unpin+0x62/0x70 RIP: 0010:dma_buf_unpin+0x62/0x70 Call Trace: dma_buf_unpin+0x62/0x70 iopt_release_pages+0xe4/0x190 iopt_unmap_iova_range+0x1c7/0x290 iopt_unmap_all+0x1a/0x30 iommufd_ioas_destroy+0x1d/0x50 iommufd_fops_release+0x93/0x150 __fput+0xfc/0x2c0 __x64_sys_close+0x3d/0x80 do_syscall_64+0x65/0x180 Take the dma_resv lock around dma_buf_unpin() in iopt_release_pages(), matching the iopt_map_dmabuf() convention. dma_buf_detach() acquires the reservation lock internally, so it must remain outside the locked region. Fixes: 8c5f9645c389 ("iommufd: Add dma_buf_pin()") Link: https://patch.msgid.link/r/20260526111034.4079-1-Ankit.Soni@amd.com Reported-by: Ankit Soni Signed-off-by: Ankit Soni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c3e84e2968abe30c516ca084e009e3b2771e9186 Author: Timur Tabi Date: Tue Jun 2 16:11:16 2026 -0500 pinctrl: PINCTRL_STMFX should depend on CONFIG_OF [ Upstream commit fd9490bdd4536a8e0911578f62164176b9000552 ] Commit e785c990adcc ("pinctrl: Kconfig: drop unneeded dependencies on OF_GPIO") removed a redundant dependecy on CONFIG_OF_GPIO for several pinctrl drivers, but this change also removed a dependency on CONFIG_OF for some of those drivers. Normally, this wouldn't be a problem, but PINCTRL_STMFX also selected MFD_STMFX, which does depend on CONFIG_OF. This conflict allows MFD_STMFX to be enabled even if CONFIG_OF is disabled. Fix this by also having PINCTRL_STMFX depend on CONFIG_OF. This is okay because the pinctrl-stmfx driver actually does depend on CONFIG_OF functions. Fixes: e785c990adcc ("pinctrl: Kconfig: drop unneeded dependencies on OF_GPIO") Signed-off-by: Timur Tabi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2518efbf2c9438a2272e3e507804ecad471c8ab2 Author: Yu-Chun Lin Date: Mon Jun 1 15:52:29 2026 +0800 dt-bindings: pinctrl: realtek,rtd1625: Fix input voltage property name [ Upstream commit 388d2fe16283d68e4be8c5317809a4a218ebeace ] The property 'input-voltage-microvolt' is a typo. Rename it to 'input-threshold-voltage-microvolt' to align with the standard pin configuration defined in pincfg-node.yaml and parsed by pinconf-generic.c. Fixes: f6ea7004e926 ("dt-bindings: pinctrl: realtek: Add RTD1625 pinctrl binding") Signed-off-by: Yu-Chun Lin Acked-by: Conor Dooley Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fae2a81f7e97640b420d310b54dc16441485d41b Author: Luca Leonardo Scorcia Date: Sun May 31 17:23:32 2026 +0100 pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins 34-39 [ Upstream commit 439bc91d20188901dac698bed4921caac76d9074 ] The correct Schmitt trigger register offset for pins 34-39 is 0xA00. Value was verified with SoC data sheet. Signed-off-by: Luca Leonardo Scorcia Fixes: 82d70627e94a ("pinctrl: mediatek: Add MT8167 Pinctrl driver") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e8a62a475e8926e46137d367abf0b8cca17ec63c Author: Luca Leonardo Scorcia Date: Sun May 31 17:22:30 2026 +0100 pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins 34-39 [ Upstream commit 1c3044cab23a056ea28da47da1cdd667a39df0b8 ] The correct Schmitt trigger register offset for pins 34-39 is 0xA00. Signed-off-by: Luca Leonardo Scorcia Fixes: 264667112ef0 ("pinctrl: mediatek: Add MT8516 Pinctrl driver") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fe034958db5fb9c92fafaa1bb242aaa47cce04cc Author: Mike Christie Date: Sat May 30 00:23:47 2026 -0500 scsi: target: Remove tcm_loop target reset handling [ Upstream commit 7c08d430835a90414cd962e3a9602e5b002dee3b ] tcm_loop_target_reset is supposed to handle all the LUNs on a target but it's only doing a TMR_LUN_RESET so only that one LUN is handled. This will cause us to return early while IOs to other LUNs are still hung in lower layers. This just removes the target reset handler for the driver because LIO doesn't support target resets and for the common case where this is run from the scsi-ml error hamdler we have already tried an abort and lun reset so waiting again is most likely useless. Fixes: 1333eee56cdf ("scsi: target: tcm_loop: Drain commands in target_reset handler") Signed-off-by: Mike Christie Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260530052349.5134-1-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 36f3faeffefbb871afd745e3365b9ad8a8d3d65f Author: Hongjie Fang Date: Fri Jun 5 19:20:34 2026 +0800 scsi: ufs: core: Handle PM commands timeout before SCSI EH [ Upstream commit 01d5e237b33931b970dd190dd6a19c5ef32c105d ] A PM START STOP sent from the UFS well-known LU resume path can race with SCSI EH: The "wl resume" task flow is: __ufshcd_wl_resume() ufshcd_set_dev_pwr_mode(UFS_ACTIVE_PWR_MODE) ufshcd_execute_start_stop() scsi_execute_cmd() blk_execute_rq <-- wait scsi_check_passthrough() <-- may retry START STOP If the first START STOP time out, SCSI EH may already recover the link and reset the device before scsi_execute_cmd() returns: scsi_timeout() scsi_eh_scmd_add() scsi_error_handler() scsi_unjam_host() scsi_eh_ready_devs() scsi_eh_host_reset() ufshcd_eh_host_reset_handler() if (hba->pm_op_in_progress) ufshcd_link_recovery() ufshcd_device_reset() ufshcd_host_reset_and_restore() ... scsi_eh_flush_done_q() <-- wakeup "wl resume" task ... <-- host still in SHOST_RECOVERY scsi_restart_operations() A later passthrough retry can then run while the host is still in SHOST_RECOVERY and hit the SCMD_FAIL_IF_RECOVERING path: scsi_queue_rq() if (scsi_host_in_recovery(shost) && cmd->flags & SCMD_FAIL_IF_RECOVERING) return BLK_STS_OFFLINE That retry completes with DID_ERROR or DID_NO_CONNECT even though EH may already have restored the device to an operational ACTIVE state. Handle these PM timeouts directly from ufshcd_eh_timed_out() instead. After ufshcd_link_recovery(), complete the timed-out command immediately if it has not been completed already. For regular SCSI commands, complete them with DID_REQUEUE to match the existing MCQ force-completion semantics and allow scsi_execute_cmd() to retry if needed. For reserved internal device-management commands, finish the request with DID_TIME_OUT without calling ufshcd_release_scsi_cmd() since those commands use different resource lifetime rules. The system_suspending flag is no longer needed because PM command timeout handling now uses pm_op_in_progress. Fixes: b8c3a7bac9b6 ("scsi: ufs: Have midlayer retry start stop errors") Signed-off-by: Hongjie Fang Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260605112034.3802540-1-hongjiefang@asrmicro.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e30b595bfbb025181561c6b4c7ed59455a9813eb Author: David Disseldorp Date: Fri Jun 5 22:16:47 2026 +1000 scsi: target: Fix hexadecimal CHAP_I handling [ Upstream commit 7e161211f1dd5288b4ea802b30e70ef919ebc3da ] A mutual CHAP handshake requires target processing of an initiator-sent CHAP_I identifier. The RFC 3720 specification states: 11.1.4. Challenge Handshake Authentication Protocol (CHAP) ... CHAP_A= CHAP_I= CHAP_C= ... Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A,A1,A2, and I are numbers CHAP_I parsing currently calls extract_param(), which returns the @identifier string (stripped of any 0b/0B or 0x/0X prefix) and a @type which indicates DECIMAL, HEX, or BASE64 encoding (based on any stripped prefix). Any HEX encoded CHAP_I string is further processed via: ret = kstrtoul(&identifier[2], 0, &id); This is incorrect for two reasons: * The @identifier string has already been stripped of the 0x/0X prefix, so skipping the first two bytes omits part of the number. * The kstrtoul() call specifies a base of 0, which will see &identifier[2] parsed as a decimal, unless a '0x' or (octal) '0' is erroneously present at that offset. Fix this by passing the (zero-offset) identifier string to kstrtoul() along with a base=16 parameter. Also add an explicit error handler for BASE64 encoding. Hex-encoded CHAP_I handling can be testing using the libiscsi EncodedI test linked below. Reported-by: Sashiko (gemini/gemini-3.1-pro-preview) Link: https://sashiko.dev/#/patchset/20260521151121.808477-1-hossu.alexandru%40gmail.com Link: https://github.com/sahlberg/libiscsi/pull/473 Fixes: 85db7391310b ("scsi: target: iscsi: Validate CHAP_R length before base64 decode") Signed-off-by: David Disseldorp Reviewed-by: Lee Duncan Reviewed-by: John Garry Link: https://patch.msgid.link/20260605122019.24146-2-ddiss@suse.de Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e992db85f18784dd8a8a091fb4abc23b0109c26c Author: Sneh Mankad Date: Fri May 29 18:25:45 2026 +0530 pinctrl: qcom: Fix resolving register base address from device node [ Upstream commit 4e31ab47997540d0ff4c9de801741bed03c1ab3f ] Commit 56ffb63749f4 ("pinctrl: qcom: add multi TLMM region option parameter") added reg-names property based register reading. However multiple platforms are not using the reg-names as they have only single TLMM register region. Commit tried to handle this using the default_region module parameter, however this condition is unreachable as the error return precedes it by just checking if reg-names property exists or not, making it impossible to use tlmm-test for the SoCs (x1e80100) which don't have reg-names property in TLMM device. Fix this by moving the default_region check at the start of the tlmm_reg_base(). Fixes: 56ffb63749f4 ("pinctrl: qcom: add multi TLMM region option parameter") Signed-off-by: Sneh Mankad Reviewed-by: Dmitry Baryshkov Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c70b5bb6f04f77ef90e047d7edc2f476e206909f Author: Yuho Choi Date: Mon Jun 1 15:20:05 2026 -0400 watchdog: unregister PM notifier on watchdog unregister [ Upstream commit a298c7302ee9584a7a1ac1e8acbede8d98ab51a4 ] watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device. Fixes: 60bcd91aafd2 ("watchdog: introduce watchdog_dev_suspend/resume") Signed-off-by: Yuho Choi Link: https://lore.kernel.org/r/20260601192005.1970805-1-dbgh9129@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit e6d93108e0a27d7e6f95c7e45017d14ba2900d32 Author: Al Viro Date: Sat May 30 03:48:34 2026 -0400 configfs: fix lockless traversals of ->s_children [ Upstream commit 9b9e8bb81c41fd27e7b57a1c936fde140548535f ] Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter. Fixes: 6f6107640625 ("configfs: Introduce configfs_dirent_lock") Reviewed-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c0f2dedd41fe14dbe076c1672214802fb42cd8c8 Author: Dmitry Vyukov Date: Fri May 29 15:09:06 2026 +0000 firmware_loader: Fix recursive lock in device_cache_fw_images() [ Upstream commit d3ec78f8f8d48a04a9fac38d47275c34645e5103 ] A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock. Fixes: ac39b3ea73aa ("firmware loader: let caching firmware piggyback on loading firmware") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+e70e4c6f6eee43357ba7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e70e4c6f6eee43357ba7 Link: https://syzkaller.appspot.com/ai_job?id=8b4af9fd-24af-423f-8acb-1159fd34c1a5 Signed-off-by: Dmitry Vyukov Link: https://patch.msgid.link/48b092a5-f49d-48a4-95f4-f65bebfc6bc3@mail.kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 86a64c049873fe4d4a6a378e27a333ab5631c4b2 Author: Aaron Ma Date: Thu May 28 16:21:10 2026 +0800 ASoC: amd: acp-sdw-sof: Bound DAI link iteration [ Upstream commit 4d992e63f52d58f52b724606c60ae7b37a1c582f ] create_sdw_dailinks() walks sof_dais until it finds an entry with initialised cleared, but sof_dais is allocated with exactly num_ends entries. If all entries are initialised, the loop reads past the end of the array. Pass the allocated entry count to create_sdw_dailinks() and stop before reading past the array. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Aaron Ma Link: https://patch.msgid.link/20260528082110.915549-2-aaron.ma@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0230471eef5902207516851dcd47c559571dded2 Author: Aaron Ma Date: Thu May 28 16:21:09 2026 +0800 ASoC: amd: acp-sdw-legacy: Bound DAI link iteration [ Upstream commit d49ecdf327cc91062d2f80996a163cf65fda1e60 ] create_sdw_dailinks() walks soc_dais until it finds an entry with initialised cleared, but soc_dais is allocated with exactly num_ends entries. If all entries are initialised, the loop reads past the end of the array. This was reported by KASAN: BUG: KASAN: slab-out-of-bounds in mc_probe+0x26b3/0x2774 [snd_acp_sdw_legacy_mach] Read of size 1 Pass the allocated entry count to create_sdw_dailinks() and stop before reading past the array. Fixes: 2981d9b0789c ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Aaron Ma Link: https://patch.msgid.link/20260528082110.915549-1-aaron.ma@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6193f7a46229b413da3ae041f2cb95de19c1a9da Author: Felix Gu Date: Fri May 29 23:31:06 2026 +0800 spi: ep93xx: fix double-free of zeropage on DMA setup failure [ Upstream commit 7886054b06f762f62054957a8f6de0f14e6b7541 ] If DMA setup fails after allocating the zeropage, the error path frees the page but leaves espi->zeropage dangling. A subsequent call to ep93xx_spi_release_dma() sees the non-NULL pointer and frees the page again. Clear the pointer after freeing in the error path of ep93xx_spi_setup_dma(). Fixes: 626a96db1169 ("spi/ep93xx: add DMA support") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260529-ep93xx-v1-1-9185070ca1fc@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e89c8578d219507a32ecb437d1c45d1689db29c7 Author: Jason Gunthorpe Date: Wed Jun 3 22:27:46 2026 -0300 IB/mlx5: Don't mangle the mr->pd inside the rereg callback [ Upstream commit 8e0a02a989c156ce17f06a645d5f075277e06b95 ] The rereg protocol expects the core code to change mr->pd and synchronize that change with the atomics and syncs. The driver should not touch it. mlx5 needed to update it in umr_rereg_pas() because mlx5r_umr_update_mr_pas() required the updated mr->pd to build the UMR. Simply switch mlx5r_umr_update_mr_pas() to use the pdn directly from the new pd and remove the mr->pd update. Fixes: 56e11d628c5d ("IB/mlx5: Added support for re-registration of MRs") Link: https://patch.msgid.link/r/7-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Assisted-by: Codex:gpt-5-5 Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9f32805f907dca875d2d6e7d5446df0f10a24264 Author: Jason Gunthorpe Date: Wed Jun 3 22:27:45 2026 -0300 IB/mlx5: Pull the pdn out of the depths of the umr machinery [ Upstream commit f387a9f06ea4f05e607a91b161963c0b19436652 ] Instead of getting the pdn deep inside the umr code, pass it in from the top. to_mpd(mr->ibmr.pd)->pdn is not safe due to the rereg races, so all the call sites need some revision to obtain the pdn in a safe way. Mark them with mlx5_mr_pdn(); following patches will go through and remove these. Cases where the XLT flags are known and do not require the PDN can pass 0, such as for mlx5_ib_dmabuf_invalidate_cb(). Also extract the DMABUF data_direct special case from inside the UMR code and into the only place that needs it, pagefault_dmabuf_mr(). The actual mr was created directly without using the UMR flow. Ultimately this will be moved into mlx5_ib_init_dmabuf_mr(). Link: https://patch.msgid.link/r/6-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Assisted-by: Codex:gpt-5-5 Signed-off-by: Jason Gunthorpe Stable-dep-of: 8e0a02a989c1 ("IB/mlx5: Don't mangle the mr->pd inside the rereg callback") Signed-off-by: Sasha Levin commit 3d11543cd14a30be969702ba4d0564f49eaed461 Author: Jason Gunthorpe Date: Wed Jun 3 22:27:44 2026 -0300 IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift() [ Upstream commit 4910483bd7ee2b40d0cc8ebd537fa33c95562029 ] The HW only processes mkc fields selected by mkey_mask. pd, qpn and mkey_7_0 are never selected so they can be left as zero. This removes a racy read of mr->pd. Fixes: e73242aa14d2 ("RDMA/mlx5: Optimize DMABUF mkey page size") Link: https://patch.msgid.link/r/5-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1a132ee4e655288d9a0937ea5109a0d038431ae9 Author: Jason Gunthorpe Date: Wed Jun 3 22:27:43 2026 -0300 RDMA/nldev: Fix locking when accessing mr->pd [ Upstream commit 50d5c02ab8e62325548bd3a6e6b758a9dcd6e7c3 ] Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer. Fixes: da5c85078215 ("RDMA/nldev: add driver-specific resource tracking") Link: https://patch.msgid.link/r/4-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5d02b9a2efd11d28d2a8feac7769686b1b871d9c Author: Jason Gunthorpe Date: Wed Jun 3 22:27:42 2026 -0300 IB/mlx5: Properly support implicit ODP rereg_mr [ Upstream commit ee7a8335069150c3f1893a697ab30bbeca00d796 ] Due to all the child mkeys in the implicit ODP configuration we cannot change anything in place for the parent mkey. Instead the whole thing needs to be rebuilt if any change is requested. If the user does not specify a translation then force the implicit values which will then fall through the logic into mlx5_ib_reg_user_mr() to allocate a completely new MR. Since implicit children were also touching the mr->pd, this removes another case where the access was racy. Fixes: ef3642c4f54d ("RDMA/mlx5: Fix error unwinds for rereg_mr") Link: https://sashiko.dev/#/patchset/20260427-security-bug-fixes-v3-0-4621fa52de0e%40nvidia.com?part=4 Link: https://patch.msgid.link/r/3-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bd68d4f768f60fbf36b66f4c037eb0c3e0eb50b4 Author: Jason Gunthorpe Date: Wed Jun 3 22:27:40 2026 -0300 IB/mlx5: Don't take the rereg_mr fallback without a new translation [ Upstream commit 55d339d200c908de83a408d023cfb7be779b0dd7 ] Jumping to mlx5_ib_reg_user_mr() without IB_MR_REREG_TRANS set will use garbage values for start, length, and iova. Recovering the original mr parameters for ODP and DMABUF to properly recreate it is too hard in this flow, so just fail it. Fixes: ef3642c4f54d ("RDMA/mlx5: Fix error unwinds for rereg_mr") Link: https://patch.msgid.link/r/1-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 07a4751ef3ccc8bfd17bfbb16e5003c03161790d Author: Bryam Vargas Date: Mon Jun 8 23:00:45 2026 +0900 ntfs: fix u16 truncation of restart-area length check [ Upstream commit 390936fb15053d8d8991ca3a22776e251a5a7f2f ] ntfs_check_restart_area() validates that the $LogFile restart area and its trailing log client record array fit within the system page size: u16 ra_ofs, ra_len, ca_ofs; ... ra_len = ca_ofs + le16_to_cpu(ra->log_clients) * sizeof(struct log_client_record); if (ra_ofs + ra_len > le32_to_cpu(rp->system_page_size) || ...) return false; ra_len is u16, but the right-hand side is computed in size_t (sizeof(struct log_client_record) == 160). Both ca_ofs and log_clients come straight from the on-disk restart area. With an on-disk log_clients of 410 the product 410 * 160 = 65600; adding ca_ofs and storing into the u16 ra_len truncates modulo 65536 (e.g. ca_ofs 64 gives ra_len 128), so the "fits in the page" check passes even though the client array described by log_clients extends far beyond the page. ntfs_check_log_client_array() then walks the array bounded only by the on-disk log_clients count: cr = ca + idx; if (cr->prev_client != LOGFILE_NO_CLIENT) ... For log_clients 410 it dereferences records up to ca + 409 * 160, ~64 KiB past the kvzalloc(system_page_size) restart-page buffer -- an out-of-bounds read of attacker-controlled extent, reachable when a crafted NTFS image is mounted (load_and_check_logfile() at mount time). This is the in-kernel analogue of CVE-2022-30789, fixed in the ntfs-3g userspace driver but never in this revived classic driver. Compute the restart-area length in a u32 so the existing bounds check rejects an over-large client array instead of being defeated by the truncation. Widen ra_ofs and ca_ofs to u32 as well: both are loaded from __le16 on-disk fields and every comparison already promotes to int/size_t, so this changes no result and keeps the declaration uniform. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Signed-off-by: Bryam Vargas Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c7a7e48e71ce915ec4cbd6e9f355590c1ecbc29a Author: Bryam Vargas Date: Sun Jun 7 20:30:00 2026 +0000 ntfs: bound the attribute-list entry in ntfs_read_inode_mount() [ Upstream commit 98634df5b1cb56c26299b7409227025ddb0167d8 ] The $MFT attribute-list walk in ntfs_read_inode_mount() validates each entry only with "(u8 *)al_entry + 6 > al_end" and "(u8 *)al_entry + le16_to_cpu(al_entry->length) > al_end", but then reads al_entry->lowest_vcn (an __le64 at offset 8) and al_entry->mft_reference (offset 16) -- fields beyond the 6 bytes proven in range. al_entry->length is attacker-controlled and only required non-zero, so a short entry (e.g. length 8) placed at the tail passes both checks while the lowest_vcn / mft_reference reads fall past al_end. al_end is ni->attr_list + attr_list_size (the on-disk size); the buffer is kvzalloc(round_up(attr_list_size, SECTOR_SIZE)), so the sector rounding usually absorbs the over-read -- but when attr_list_size is a multiple of SECTOR_SIZE there is no slack and a crafted $MFT attribute list produces an out-of-bounds read at mount time. Validate the entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing it, matching the bound the other attribute-list walks now use. The validator already requires the length to cover the fixed header, which makes the separate "!al_entry->length" check redundant, so drop it too. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Signed-off-by: Bryam Vargas Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 44885c9b45eb4082fb7f558590d84bb254a08e94 Author: Bryam Vargas Date: Sun Jun 7 20:30:00 2026 +0000 ntfs: bound the look-ahead attribute-list entry in ntfs_external_attr_find() [ Upstream commit 344b18f389f9934d59c7b0cf3d20541ea2e0da58 ] When resolving an attribute lookup with a non-zero @lowest_vcn, ntfs_external_attr_find() peeks at the next $ATTRIBUTE_LIST entry to decide whether to keep searching, but bounds that not-yet-validated entry only with "(u8 *)next_al_entry + 6 < al_end" (which proves just bytes 0..6 are in range) and "(u8 *)next_al_entry + length <= al_end" with an attacker-controlled, non-8-aligned length. It then reads next_al_entry->lowest_vcn (an __le64 at offset 8) and the name at next_al_entry->name_offset, both of which can lie past al_end -- the exact end of the kvmalloc'd attribute-list buffer (allocated at the on-disk attr_list_size, no rounding). A crafted on-disk $ATTRIBUTE_LIST whose last entry sits a few bytes before al_end therefore yields a slab out-of-bounds read when the inode is read. Validate the look-ahead entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing lowest_vcn and the name, so the same fixed-header, length and name bounds the main attribute-list walk uses now guard this read too. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Signed-off-by: Bryam Vargas Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 55e97648f7753c6097cb682d24d1abcfe878e812 Author: Bryam Vargas Date: Sun Jun 7 20:30:00 2026 +0000 ntfs: validate resident attribute lists and harden the validator [ Upstream commit 7d19e1ffee084c4f7d321a360c14ba43404f7cc8 ] A base inode's $ATTRIBUTE_LIST is sanity-checked by load_attribute_list() only on the non-resident path; ntfs_read_locked_inode() copies a *resident* attribute list into ni->attr_list with a plain memcpy() and no validation at all. Every subsequent walk of ni->attr_list -- ntfs_external_attr_find(), ntfs_inode_attach_all_extents() and ntfs_attrlist_need() -- then trusts the entries are well-formed and reads attr_list_entry fixed-header fields (lowest_vcn at offset 8, mft_reference at offset 16, and the name) with bounds that assume validation already happened. A crafted resident attribute list therefore reaches those walks unvalidated and can drive out-of-bounds reads of the attribute-list buffer. load_attribute_list() itself reads ale->name_offset (offset 7), ale->mft_reference (offset 16) and the name length under only an "al < al_start + size" bound, so its own validation loop can over-read the fixed header of a truncated trailing entry by a few bytes. Factor the per-entry validation into ntfs_attr_list_entry_is_valid(), which requires each entry's fixed header (offsetof(struct attr_list_entry, name)) to be in range before any field is dereferenced, that ale->length is a multiple of 8 covering the fixed header plus the name, and that the entry is in use and carries a live MFT reference. ntfs_attr_list_is_valid() walks the buffer with it and checks the entries tile it exactly. Use the list validator in load_attribute_list() (replacing the open-coded loop, closing its own over-read) and on the resident path in ntfs_read_locked_inode() (which previously skipped validation entirely); patches 2/3 reuse the per-entry helper at the other two attribute-list walks. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Signed-off-by: Bryam Vargas Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 4010a227f4a5aeaae1f328b79687a9c6383da6eb Author: Mark Harmstone Date: Wed Apr 22 15:03:35 2026 +0100 btrfs: don't force DIO writes to be serialized [ Upstream commit 14f9161e872072075284b8afa4c3f929e199a0f6 ] Before btrfs switched to the new mount API in 2023, we were setting SB_NOSEC in btrfs_mount_root(). This flag tells the VFS that the filesystem may have files which don't have security xattrs, enabling it to do some optimizations. Unfortunately this was missed in the transition, meaning that IS_NOSEC will always return false for a btrfs inode. This means that btrfs_direct_write() calls will always get the inode lock exclusively, meaning that DIO writes to the same file will be serialized. On my machine, this one-line change results in a ~59% improvement in DIO throughput: Before patch: test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=io_uring, iodepth=64 ... fio-3.39 Starting 32 processes test: Laying out IO file (1 file / 1024MiB) Jobs: 32 (f=32): [w(32)][100.0%][w=764MiB/s][w=195k IOPS][eta 00m:00s] test: (groupid=0, jobs=32): err= 0: pid=586: Wed Apr 22 13:03:04 2026 write: IOPS=202k, BW=787MiB/s (826MB/s)(46.1GiB/60012msec); 0 zone resets bw ( KiB/s): min=498714, max=1199892, per=100.00%, avg=806659.03, stdev=4229.94, samples=3808 iops : min=124677, max=299971, avg=201661.82, stdev=1057.49, samples=3808 cpu : usr=0.32%, sys=1.27%, ctx=8329204, majf=0, minf=1163 IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=100.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued rwts: total=0,12094328,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): WRITE: bw=787MiB/s (826MB/s), 787MiB/s-787MiB/s (826MB/s-826MB/s), io=46.1GiB (49.5GB), run=60012-60012msec After patch: test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=io_uring, iodepth=64 ... fio-3.39 Starting 32 processes test: Laying out IO file (1 file / 1024MiB) Jobs: 32 (f=32): [w(32)][100.0%][w=1255MiB/s][w=321k IOPS][eta 00m:00s] test: (groupid=0, jobs=32): err= 0: pid=572: Wed Apr 22 13:13:46 2026 write: IOPS=320k, BW=1250MiB/s (1311MB/s)(73.3GiB/60003msec); 0 zone resets bw ( MiB/s): min= 619, max= 2289, per=100.00%, avg=1251.28, stdev= 9.64, samples=3808 iops : min=158538, max=586025, avg=320320.80, stdev=2468.97, samples=3808 cpu : usr=0.35%, sys=11.50%, ctx=1584847, majf=0, minf=1160 IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=100.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued rwts: total=0,19203309,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): WRITE: bw=1250MiB/s (1311MB/s), 1250MiB/s-1250MiB/s (1311MB/s-1311MB/s), io=73.3GiB (78.7GB), run=60003-60003msec The script to reproduce that: #!/bin/bash mkfs.btrfs -f /dev/nvme0n1 mount /dev/nvme0n1 /mnt/test mkdir /mnt/test/nocow chattr +C /mnt/test/nocow fio /root/test.fio # cat /root/test.fio [global] rw=randwrite ioengine=io_uring iodepth=64 size=1g direct=1 startdelay=20 force_async=4 ramp_time=5 runtime=60 group_reporting=1 numjobs=32 time_based disk_util=0 clat_percentiles=0 disable_lat=1 disable_clat=1 disable_slat=1 filename=/mnt/test/nocow/fiofile [test] name=test bs=4k stonewall This was on a VM with 8 cores and 8GB of RAM, with a real NVMe exposed through PCI passthrough. The figures for XFS and ext4 in comparison are both about ~3GB/s. Fixes: ad21f15b0f79 ("btrfs: switch to the new mount API") Signed-off-by: Mark Harmstone Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 44f37dc3b3f9fcde52934ccfa6fc014c63762086 Author: Samuel Moelius Date: Fri Jun 5 18:52:06 2026 +0000 thermal: testing: reject missing command arguments [ Upstream commit ef3e98b0aa4b348f44065d7130251273c83bd204 ] The thermal testing debugfs command parser splits commands at ':' and passes the right-hand side to the command implementation. Commands such as deltz, tzaddtrip, tzreg, and tzunreg require a zone id, but writing one of those command names without ':' leaves the argument pointer NULL. The command implementations parse the id with sscanf(arg, "%d", ...), so the missing-argument form dereferences a NULL pointer from the debugfs write path. Reject missing arguments in tt_command_exec() before calling handlers that require an id. Fixes: f6a034f2df42 ("thermal: Introduce a debugfs-based testing facility") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Link: https://patch.msgid.link/20260605185212.2491144-1-sam.moelius@trailofbits.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit af57a748c4210a00d69692caefab1d3cff7fff72 Author: Pengjie Zhang Date: Wed Jun 3 13:56:35 2026 +0800 cpufreq: Documentation: fix conservative governor freq_step description [ Upstream commit 03120e1425262c7d11f93362a88e579a1720390b ] The conservative governor documentation incorrectly states that setting freq_step to 0 will use the default 5% frequency step. In reality, since at least commit 8e677ce83bf4 ("[CPUFREQ] conservative: fixup governor to function more like ondemand logic"), freq_step=0 has always caused the governor to skip frequency updates entirely. Correct the documentation to reflect the actual behavior: freq_step=0 disables frequency changes by the governor entirely. Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation") Signed-off-by: Pengjie Zhang Reviewed-by: Zhongqiu Han [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20260603055635.1549943-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 666495333fc27e9ec46eafda8d77a1cecc528f92 Author: Tony W Wang-oc Date: Tue Jun 9 03:03:59 2026 +0800 ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver() [ Upstream commit 66c62e6773c54ce5233eb21c6d48999c3747bd13 ] Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init(), but it didn't check whether a cpuidle driver was already registered. For example, on Intel platforms, if the intel_idle driver is already loaded, the code would still evaluate the _CST object in the ACPI table and attempt to register the acpi_idle driver. This registration would fail with -EBUSY due to the existing check in cpuidle_register_driver. Add a check at the beginning of acpi_processor_register_idle_driver() to avoid unnecessary _CST evaluate and potential registration failures. Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Tony W Wang-oc Link: https://patch.msgid.link/20260608190359.3254-1-TonyWWang-oc@zhaoxin.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit bb9c7a9c5e8bd35ffb07747bcce29951883b4f63 Author: Yuho Choi Date: Wed Jun 3 12:31:08 2026 -0400 ACPI: IPMI: Fix message kref handling on dead device [ Upstream commit 63320db6a5d84ec3fed8b3d36ba5244d07ddd108 ] acpi_ipmi_space_handler() takes an extra reference on tx_msg before checking whether the selected IPMI device is dead. The reference belongs to the tx_msg_list entry and is normally dropped by ipmi_cancel_tx_msg() or ipmi_flush_tx_msg() after the message is removed from the list. On the dead-device path, the message has not been queued yet, but the error path still calls ipmi_msg_release() directly. That bypasses kref_put() and frees tx_msg while the queued-message reference is still recorded in the kref count. Take the queued-message reference only after the dead-device check succeeds, immediately before adding tx_msg to the list. Fixes: 7b9844772237 ("ACPI / IPMI: Add reference counting for ACPI IPMI transfers") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260603163108.2149359-1-dbgh9129@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a4c95b6221cb2972a94ed72663c09bd5b0b6dea4 Author: Sechang Lim Date: Mon Jun 8 05:00:00 2026 +0000 bpf: Fix NULL pointer dereference in bpf_task_from_vpid() [ Upstream commit 50dff00615522f3ec03449680ca23beb4cfc549c ] bpf_task_from_vpid() looks up a task in the pid namespace of the current task, via find_task_by_vpid(): find_task_by_vpid(vpid) find_task_by_pid_ns(vpid, task_active_pid_ns(current)) find_pid_ns(nr, ns) -> idr_find(&ns->idr, nr) cgroup_skb programs run in softirq, which may interrupt a task that is itself in do_exit(). Once that task has passed exit_notify() -> release_task() -> __unhash_process(), its thread_pid is cleared, so task_active_pid_ns(current) returns NULL and find_pid_ns() dereferences &NULL->idr: BUG: kernel NULL pointer dereference, address: 0000000000000050 RIP: 0010:idr_find+0x11/0x30 lib/idr.c:176 Call Trace: find_pid_ns kernel/pid.c:370 [inline] find_task_by_pid_ns+0x3b/0xe0 kernel/pid.c:485 bpf_task_from_vpid+0x5b/0x200 kernel/bpf/helpers.c:2916 bpf_prog_run_array_cg+0x17e/0x530 kernel/bpf/cgroup.c:81 __cgroup_bpf_run_filter_skb+0x12b/0x250 kernel/bpf/cgroup.c:1612 sk_filter_trim_cap+0x1dc/0x4c0 net/core/filter.c:148 tcp_v4_rcv+0x18d1/0x2200 net/ipv4/tcp_ipv4.c:2223 do_exit+0xa63/0x1270 kernel/exit.c:1010 get_signal+0x141c/0x1530 kernel/signal.c:3037 Bail out when current has no pid namespace. Fixes: 675c3596ff32 ("bpf: Add bpf_task_from_vpid() kfunc") Signed-off-by: Sechang Lim Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260608050001.2545245-1-rhkrqnwk98@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit f97ecf17813acec204eb0575e0ead6718e07d970 Author: Bartosz Golaszewski Date: Wed Jun 3 10:26:26 2026 +0200 powerpc/8xx: implement get_direction() in cpm1 [ Upstream commit 052f67a1ae6ffa6e43c82193bf2e6c0dfd2e6d8f ] The lack of get_direction() callbacks in this driver causes GPIOLIB to emit a warning. Implement them for 16- and 32-bit variants. Reported-by: Christophe Leroy Closes: https://lore.kernel.org/all/63487206f6e5a93eaf9f41784317fe99d394312f.1780399750.git.chleroy@kernel.org/ Signed-off-by: Bartosz Golaszewski Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Tested-by: Christophe Leroy (CS GROUP) Reviewed-by: Linus Walleij Reviewed-by: Christophe Leroy (CS GROUP) [Maddy: Fixed the Fixes tag] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260603-powerpc-8xx-cpm1-get-dir-v1-1-2ae1c9a5b992@oss.qualcomm.com Signed-off-by: Sasha Levin commit 3abc13ec3ac28c343ad7e7b7496e807b924f0edd Author: Bryam Vargas Date: Sat Jun 6 07:43:45 2026 +0000 wifi: mac80211: bound S1G TIM PVB walk to the TIM element [ Upstream commit b224d18b1e5d1cddfc67f63f41d80023b2ec8889 ] ieee80211_s1g_check_tim() parses the S1G Partial Virtual Bitmap (PVB) of a received TIM element. The TIM is handed in as the element payload: ieee802_11_parse_elems_full() stores elems->tim = elem->data and elems->tim_len = elem->datalen (net/mac80211/parse.c), so the valid bytes are [tim, tim + tim_len). When walking the encoded blocks the function passes the walker an end sentinel of (const u8 *)tim + tim_len + 2, i.e. two bytes past the end of the element. ieee80211_s1g_find_target_block() loops while (ptr + 1 <= end) and dereferences ptr (and the per-mode ieee80211_s1g_len_*() helpers read *ptr), so it can read up to two bytes beyond the TIM element -- an out-of-bounds read of adjacent skb/heap data when the TIM is the last element in the frame. The +2 appears to account for the element id/len header, but tim already points past that header at the element payload, so the addend is wrong. Pass the correct element end, (const u8 *)tim + tim_len. Fixes: e0c47c6229c2 ("wifi: mac80211: support parsing S1G TIM PVB") Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260606074341.49135-1-hexlabsecurity@proton.me Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 32aefd60ae40f1d814dd9739da8769ab30ea5458 Author: David Gow Date: Sat Jun 6 10:03:15 2026 +0800 kunit:tool: Don't write to stdout when it should be disabled [ Upstream commit 29afed142d64e181749214072315c976f8510bd7 ] The kunit_parser module accepts a 'printer' object which is used as a destination for all output. This is typically set to stdout, so that the parsed results are visible, but can be set to a special 'null_printer' to implement options where not all results are always printed. However, there are a few places where use of stdout is hardcoded, notably in handling crashed tests and in outputting the colour escape sequences. Properly use the specified printer for all output. This is okay for the colour handling (as this is already gated behind isatty() anyway), and also for the crash handling, as cases where printer != stdout are separately printed afterwards. Link: https://lore.kernel.org/r/20260606020317.264178-1-david@davidgow.net Fixes: 062a9dd9bad7 ("kunit: tool: Only print the summary") Signed-off-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 440a2fdbb40608d55a7b11f2be53592a3785131d Author: Mykyta Yatsenko Date: Sun Jun 7 13:30:41 2026 -0700 bpf: Fix NMI/tracepoint re-entry deadlock on lru locks [ Upstream commit 89edbdfc5d0308cef57b71359331de5c4ddbf763 ] NMI and tracepoint BPF programs can re-enter the per-CPU or global LRU lock that bpf_lru_pop_free()/push_free() already hold on the same CPU, AA-deadlocking. Lockdep reports "inconsistent {INITIAL USE} -> {IN-NMI}" on &l->lock (syzbot c69a0a2c816716f1e0d5) and "possible recursive locking detected" on &loc_l->lock (syzbot 18b26edb69b2e19f3b33). Prior trylock and rqspinlock based fixes (see links) were nacked because compromised on reliability. This patch converts every LRU lock site to rqspinlock_t and adds a recovery path for some failure windows to avoid node leaks. Failure recovery: - *_pop_free top-level: return NULL; prealloc_lru_pop() already treats that as no-free-element (-ENOMEM). - Cross-CPU steal: skip the victim's locked loc_l, try next CPU. - Post-steal local lock fail: publish stolen node to lockless per-CPU free_llist; next pop on this CPU picks it up. - push_free fail: mark node pending_free=1. __local_list_flush(), __local_list_pop_pending() reclaim the node from pending_list. __bpf_lru_list_shrink_inactive() reclaims the node from inactive list. Nodes from active list are reclaimed by __bpf_lru_list_shrink() or after __bpf_lru_list_rotate_active() demotes it to the inactive. Fixes: 3a08c2fd7634 ("bpf: LRU List") Reported-by: syzbot+c69a0a2c816716f1e0d5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c69a0a2c816716f1e0d5 Reported-by: syzbot+18b26edb69b2e19f3b33@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=18b26edb69b2e19f3b33 Link: https://lore.kernel.org/bpf/CAPPBnEYO4R+m+SpVc2gNj_x31R6fo1uJvj2bK2YS1P09GWT6kQ@mail.gmail.com/ Link: https://lore.kernel.org/bpf/CAPPBnEZmFA3ab8Uc=PEm0bdojZy=7T_F5_+eyZSHyZR3MBG4Vw@mail.gmail.com/ Link: https://lore.kernel.org/bpf/20251030030010.95352-1-dongml2@chinatelecom.cn/ Link: https://lore.kernel.org/bpf/20260119142120.28170-1-leon.hwang@linux.dev/ Signed-off-by: Mykyta Yatsenko Link: https://lore.kernel.org/r/20260607-lru_map_spin-v3-1-bcd9332e911b@meta.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 716566c6c82c6a4340cbee820557ba9ef00ac4dc Author: Christian Brauner Date: Sun Jun 7 11:40:28 2026 +0200 filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n [ Upstream commit 4bbcff264b678859cc404669bd145bcd6819804b ] The CONFIG_FILE_LOCKING=n stub for break_lease() takes a 'bool wait' argument, whereas the CONFIG_FILE_LOCKING=y version and every caller pass an openmode as an 'unsigned int mode'. The mismatch was introduced when __break_lease() was reworked to use flags: only the stub was switched to 'bool wait', a stray leftover from the neighbouring break_layout() helper. The real prototype kept 'unsigned int mode'. This was harmless until O_WRONLY changed from the octal literal 00000001 to (1 << 0). clang's -Wtautological-constant-compare then fires on the implicit shift-to-bool conversion at the first FILE_LOCKING=n caller: fs/open.c:112:29: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] 112 | error = break_lease(inode, O_WRONLY); Restore the stub's parameter to 'unsigned int mode' so it matches the real prototype and every caller. The stub still just returns 0, so there is no functional change; it removes the type inconsistency and silences the warning. Root cause diagnosed by Nathan Chancellor. Fixes: 4be9f3cc582a ("filelock: rework the __break_lease API to use flags") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202606071029.DKCs8WOs-lkp@intel.com/ Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 2f55fa28011c97d6495d5787808db10a8c2d690d Author: David Carlier Date: Sat May 23 16:26:21 2026 +0100 netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag [ Upstream commit e052f920773b73be49eb4d8702a9f85de7464363 ] The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the decrement still happens and wraps it to 255. The break only leaves the inner switch -- a later path entry can set info->indev back to a real device, and we end up returning with num_encaps == 255. nft_dev_forward_path() then walks info.encap[] (size 2) up to num_encaps, which means an OOB stack read and a bogus count copied into the route descriptor. Should only happen on a malformed bridge path stack, hence the WARN, but worth handling sanely. Move the decrement out of the WARN. [ While at this, remove the WARN_ON_ONCE since this can only happen with a buggy bridge path stack --pablo ]. Fixes: e990cef6516d ("netfilter: flowtable: add bridge vlan filtering support") Signed-off-by: David Carlier Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit be9eaf2bb5db4ad3de61ef739fd268fd7f135737 Author: David Windsor Date: Fri Jun 5 10:57:07 2026 -0400 bpf: Reject sleepable BPF_LSM_CGROUP programs at load time [ Upstream commit 5b038319be442c620f774e6fc9e9283deeca1c75 ] The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should not attach any sleepable BPF programs there. Add support to the verifier to explicitly reject attempts to load sleepable BPF programs destined for LSM cgroup attachment. Without this, we get the following splat from a BPF_LSM_CGROUP program marked BPF_F_SLEEPABLE attached to file_open when it calls bpf_get_dentry_xattr(): BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load preempt_count: 0, expected: 0 RCU nest depth: 2, expected: 0 Call Trace: down_read+0x76/0x480 ext4_xattr_get+0x11f/0x700 __vfs_getxattr+0xf0/0x150 bpf_get_dentry_xattr+0xbb/0xf0 bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85 __cgroup_bpf_run_lsm_current+0x326/0x840 bpf_trampoline_6442534646+0x62/0x14d security_file_open+0x34/0x60 do_dentry_open+0x340/0x1260 vfs_open+0x7a/0x440 path_openat+0x1bac/0x30a0 libbpf provides a .s named section variant for every sleepable program type except lsm_cgroup, reflecting that per-cgroup LSM programs are intended to only run in a non-sleepable context. The above splat was obtained by bypassing libbpf by using bpf(2) directly. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Signed-off-by: David Windsor Acked-by: Yonghong Song Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20260605145707.608579-1-dwindsor@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 23b933c6223f873ce7923704365b6efcab24d8b8 Author: Mykyta Yatsenko Date: Wed Apr 22 12:41:09 2026 -0700 bpf: Verifier support for sleepable tracepoint programs [ Upstream commit 8cfb77d3092052b52582e804e644202e2b10167a ] Allow BPF_PROG_TYPE_RAW_TRACEPOINT, BPF_PROG_TYPE_TRACEPOINT, and BPF_TRACE_RAW_TP (tp_btf) programs to be sleepable by adding them to can_be_sleepable(). For BTF-based raw tracepoints (tp_btf), add a load-time check in bpf_check_attach_target() that rejects sleepable programs attaching to non-faultable tracepoints with a descriptive error message. For raw tracepoints (raw_tp), add an attach-time check in bpf_raw_tp_link_attach() that rejects sleepable programs on non-faultable tracepoints. The attach-time check is needed because the tracepoint name is not known at load time for raw_tp. The attach-time check for classic tracepoints (tp) in __perf_event_set_bpf_prog() was added in the previous patch. Replace the verbose error message that enumerates allowed program types with a generic "Program of this type cannot be sleepable" message, since the list of sleepable-capable types keeps growing. Signed-off-by: Mykyta Yatsenko Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/bpf/20260422-sleepable_tracepoints-v13-4-99005dff21ef@meta.com Signed-off-by: Kumar Kartikeya Dwivedi Stable-dep-of: 5b038319be44 ("bpf: Reject sleepable BPF_LSM_CGROUP programs at load time") Signed-off-by: Sasha Levin commit a88a476986908b32d1f9d212b2d21fbbb573bcbb Author: Thomas Weißschuh Date: Mon May 4 08:30:53 2026 +0200 riscv: alternative: Also patch the CFI vDSO [ Upstream commit d3e0634787a234b40a740b9c398fd320a68db81c ] The dedicated vDSO for CFI-enabled userspace can also contain alternative entries. Patch those, too. Fixes: ccad8c1336b6 ("arch/riscv: add dual vdso creation logic and select vdso based on hw") Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-4-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit a24b3d9c8d70b05776b2260b4e60de43614da61e Author: Thomas Weißschuh Date: Mon May 4 08:30:52 2026 +0200 riscv: alternative: Pass vDSO start as parameter to apply_vdso_alternatives() [ Upstream commit 6386161abb02880ace2cc965e73f7857b351706c ] The dedicated vDSO with CFI should also be patched in the same way. To prepare for that move the currently hardcoded vDSO start symbol into a parameter. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-3-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley Stable-dep-of: d3e0634787a2 ("riscv: alternative: Also patch the CFI vDSO") Signed-off-by: Sasha Levin commit dd381ed4528a737a12f9c46013a56ac22423f527 Author: Thomas Weißschuh Date: Mon May 4 08:30:51 2026 +0200 riscv: alternative: Use IS_ENABLED() over ifdeffery for apply_vdso_alternatives() [ Upstream commit 4fd6505f189d447abbed1f1f6fe6b82649f27a46 ] IS_ENABLED() allows better compilation coverage while still optimizing away all the dead code. Also it will make some upcoming changes easier. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-2-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley Stable-dep-of: d3e0634787a2 ("riscv: alternative: Also patch the CFI vDSO") Signed-off-by: Sasha Levin commit c2ac9287e89916da684c2a548798351e63eb59ee Author: Kyle Zeng Date: Sat Jun 6 17:41:29 2026 -0700 ALSA: seq: Clear variable event pointer on read [ Upstream commit 705dd6dcbc0ea87351c660c1a6443f85f1001c76 ] snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260607004129.61345-1-kylebot@openai.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ec54e525cb6b5bfa1164ab519901fe2e71beb4c8 Author: Rui Qi Date: Sat Jun 6 20:17:59 2026 -0600 riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe [ Upstream commit 8ac35bac70e7e581d673b76878f7691cdadc33b8 ] In the non-frame-pointer version of walk_stackframe, each value read from the stack is treated as a potential return address and has 0x4 subtracted before being used as the program counter. This was intended to convert the return address (the instruction after a call) back to the call site, but it is incorrect: 1. RISC-V has variable-length instructions due to the RVC (compressed instruction) extension. A call instruction can be either 4 bytes (regular) or 2 bytes (compressed, e.g. c.jal). Subtracting a fixed 0x4 assumes all call instructions are 4 bytes, which is wrong for compressed instructions. 2. Stack traces conventionally report return addresses, not call sites. Other architectures (ARM64, x86, ARM) do not subtract instruction size from return addresses in their stack unwinding code. 3. The frame-pointer version of walk_stackframe already dropped the -0x4 offset. Commit b785ec129bd9 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") replaced "pc = frame->ra - 0x4" with ftrace_graph_ret_addr(), and the commit message explicitly noted that "the original calculation, pc = frame->ra - 4, is buggy when the instruction at the return address happened to be a compressed inst." The non-FP version was simply overlooked. Remove the bogus -0x4 offset to match the FP version and the conventions used by other architectures. Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly") Signed-off-by: Rui Qi Link: https://patch.msgid.link/20260603115329.791603-2-qirui.001@bytedance.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 79f51eb2feec75c4c2bcea9433ca9ab5fd3519d0 Author: Hui Wang Date: Sat Jun 6 20:17:54 2026 -0600 riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool [ Upstream commit 2b2b207e1162e577cd6208e184d3d3a0fcfa9cca ] In the original sbi_cpu_is_stopped(), if rc doesn't equal to the SBI_HSM_STATE_STOPPED, it will return rc to the caller directly. But there is a hidden problem, the rc could be SBI_HSM_STATE_STARTED, if so, this function will report cpu stopped while the cpu isn't really stopped. Furthermore, from the name of cpu_is_stopped(), it gives a sense the return value is a bool type, true means the cpu is stopped, conversely false means the cpu is not stopped. Here change the return value type to bool and change the callers accordingly. This could fix the above two issues. Fixes: f1e58583b9c7c ("RISC-V: Support cpu hotplug") Signed-off-by: Hui Wang Link: https://patch.msgid.link/20260413123515.48423-1-hui.wang@canonical.com [pjw@kernel.org: cleaned up some of the pr_warn() messages] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit b02c5430ef2c0858fa182429181f801b5fe11424 Author: Cássio Gabriel Date: Fri Jun 5 12:48:27 2026 -0300 ALSA: pcm: Fix unlocked runtime state reads in xfer ioctls [ Upstream commit 98fe3988a2efe89a1a1ded213a0561e6543e94e2 ] The recent runtime state locking cleanup converted several PCM ioctl state checks to snd_pcm_get_state(), including snd_pcm_pre_prepare(), snd_pcm_drain() and snd_pcm_kernel_ioctl(). The native and compat xfer ioctl paths still sample runtime->state directly before dispatching to the PCM transfer helpers, and snd_pcm_common_ioctl() still samples the DISCONNECTED state directly in its common precheck. Use snd_pcm_get_state() for those ioctl-side prechecks as well. This keeps the externally visible ioctl entry checks consistent with the stream-locked state access used by the recent PCM state-read cleanup. Fixes: 032322b44c02 ("ALSA: pcm: oss: use proper stream lock for runtime->state access") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260605-alsa-pcm-xfer-state-helper-v1-1-eba97cecf820@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 890dddd48ecd698d28eeb6abe49709428dd78d98 Author: HyeongJun An Date: Sat Jun 6 13:09:13 2026 +0900 ALSA: seq: Fix partial userptr event expansion [ Upstream commit 2b7bd6f548292aec92a386deebe62324d21d62a9 ] snd_seq_expand_var_event_at() clamps the number of bytes to copy to the remaining variable-event length, but passes the original buffer size to expand_var_event(). For SNDRV_SEQ_EXT_USRPTR events, expand_var_event() copies exactly the size argument from userspace. On the final chunk, when the remaining event data is shorter than the caller's buffer, this can read past the declared event data and can spuriously fail with -EFAULT if the extra bytes cross an unmapped page. Pass the clamped length instead. The chained and kernel-backed paths already reclamp in dump_var_event(), but the user-pointer path handles the size directly. Fixes: ea46f79709b6 ("ALSA: seq: Add snd_seq_expand_var_event_at() helper") Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260606040913.230213-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d0cafe6ed8d1f6d0097eda31d85f5760d4f359c2 Author: Tristan Madani Date: Tue Apr 21 13:50:18 2026 +0000 wifi: wcn36xx: fix OOB read from short trigger BA firmware response [ Upstream commit b5e6f21923ca89d90256e7346301056f6502691e ] The firmware response length is only checked against sizeof(*rsp) (20 bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read at buf + 20 without verifying the response contains it. This causes an out-of-bounds read of stale heap data, corrupting the BA session state. Add validation that the response includes the candidate data. Fixes: 16be1ac55944 ("wcn36xx: Parse trigger_ba response properly") Signed-off-by: Tristan Madani Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260421135018.352774-4-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f987efff29a5fe45320ea5991c9d5cb98b676953 Author: Tristan Madani Date: Tue Apr 21 13:50:17 2026 +0000 wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication [ Upstream commit df2187acfca6c6cca372c5d35f42394d9c270b09 ] The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message. Fixes: 43efa3c0f241 ("wcn36xx: Implement print_reg indication") Signed-off-by: Tristan Madani Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260421135018.352774-3-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 18813b90032bfaafb225906a4d2b51be4dfc02c3 Author: Tristan Madani Date: Tue Apr 21 13:50:16 2026 +0000 wifi: wcn36xx: fix heap overflow from oversized firmware HAL response [ Upstream commit 88a240d86d3d64521f9194abe185ac71cc74d0bd ] The firmware response dispatcher copies all synchronous HAL responses into the 4096-byte hal_buf without validating the response length. A response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow with firmware-controlled content. Add a bounds check on the response length. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Tristan Madani Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260421135018.352774-2-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 319b82e8b46edaf557436ad858e734e583f78ec9 Author: Christian Brauner Date: Tue May 26 10:57:06 2026 +0200 kernfs: link kn to its parent before the LSM init hook [ Upstream commit 6cccc49b027c7551ffc1d2532f2ef1922661f3da ] After commit 12e9e3cd03b5 ("simpe_xattr: use per-sb cache"), kernfs_xattr_set() and kernfs_xattr_get() compute the cache via kernfs_root(kn) before any other check. kernfs_root(kn) walks kn->__parent first and falls back to kn->dir.root, both of which are NULL on a freshly kmem_cache_zalloc()'d kn. kn->__parent was being set in kernfs_new_node() after __kernfs_new_node() returned, and kn->dir.root is set even later by kernfs_create_dir_ns() / kernfs_create_empty_dir(). The LSM kernfs_init_security hook is invoked from inside __kernfs_new_node(), before either field has been initialized. selinux_kernfs_init_security() ends with kernfs_xattr_set(kn, XATTR_NAME_SELINUX, ...). kernfs_root(kn) then returns NULL, and &((struct kernfs_root *)NULL)->xa_cache evaluates to offsetof(struct kernfs_root, xa_cache) which faults: BUG: kernel NULL pointer dereference, address: 00000000000000e0 RIP: 0010:simple_xattr_set+0x27/0x8b0 Call Trace: kernfs_xattr_set+0x63/0xb0 selinux_kernfs_init_security+0x13b/0x270 security_kernfs_init_security+0x36/0xc0 __kernfs_new_node+0x182/0x290 kernfs_new_node+0x80/0xc0 kernfs_create_dir_ns+0x2b/0xa0 cgroup_create+0x116/0x380 cgroup_mkdir+0x7c/0x1a0 Reproduces deterministically at PID 1 (systemd) on an SELinux-enabled distro. The first cgroup mkdir under /sys/fs/cgroup with a labelled parent panics the kernel. The LSM hook's contract is that the kn_dir argument is the parent of the new kn, so kn->__parent should already point at kn_dir when the hook runs. Move kernfs_get(parent) and rcu_assign_pointer of kn->__parent from kernfs_new_node() into __kernfs_new_node() right before the security hook, and unwind the parent reference on the err_out4 path. kernfs_root(kn) then takes its parent branch during the hook and returns parent->dir.root, which is the correct root. This also closes the same-shape latent bug in kernfs_xattr_get() (which today is hidden only by kernfs_iattrs_noalloc() returning NULL on a fresh kn). Fixes: 12e9e3cd03b5 ("simpe_xattr: use per-sb cache") Reported-by: Calum Mackay Closes: https://lore.kernel.org/all/5386153f-9112-4971-98fc-de90d7aae2c6@oracle.com/ Link: https://patch.msgid.link/20260526-ablief-demut-wehen-aef8446ef5c9@brauner Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 86c65ca2d69b8501542991f6aca1417b2abc6261 Author: Miklos Szeredi Date: Fri Jun 5 15:53:19 2026 +0200 simpe_xattr: use per-sb cache [ Upstream commit 1e7cd8a53b72a58a44c4d282aed95f6ce0e76db0 ] Move the hash table to the super block to remove excessive overhead in case of small number of xattrs per inode. Add linked list to the inode, used for listxattr and eviction. Listxattr uses rcu protection to iterate the list of xattrs. Before being made per-sb, lazy allocation was protected by inode lock. Now inode lock no longer provides sufficient exclusion, so use cmpxchg() to ensure atomicity. Though I haven't found a description of this pattern, after some research it seems that cmpxchg_release() and READ_ONCE() should provide the necessary memory barriers. Use simple_xattr_free_rcu() in simple_xattrs_free(). This is needed because the hash table is now shared between inodes and lookup on a different inode might be running the compare function on the just freed element within the RCU grace period. Following stats are based on slabinfo diff, after creating 100k empty files, then adding a "user.test=foo" xattr to each: v7.0 (no rhashtable): File creation: 993.40 bytes/file Xattr addition: 79.99 bytes/file v7.1-rc2 (per-inode rhashtable): File creation: 939.73 bytes/file Xattr addition: 1296.08 bytes/file v7.1-rc2 + this patch (per-sb rhashtable) File creation: 946.84 bytes/file Xattr addition: 111.86 bytes/file The overhead of a single xattr is reduced to nearly v7.0 levels. The per xattr overhead is slightly larger due to the addition of three pointers to struct simple_xattr. Fixes: b32c4a213698 ("xattr: add rhashtable-based simple_xattr infrastructure") Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260605135322.2632068-5-mszeredi@redhat.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit deb90fdafd52dfd96161175faba46c3e49d20807 Author: Miklos Szeredi Date: Fri Jun 5 15:53:18 2026 +0200 simple_xattr: change interface to pass struct simple_xattrs ** [ Upstream commit 076e5cef28e27febfc09b5f72544d2b857c75201 ] Change the simple_xattr API to accept pointer-to-pointer (struct simple_xattrs **) instead of pointer. This allows the functions to handle lazy allocation internally without requiring callers to use simple_xattrs_lazy_alloc(). The simple_xattr_set(), simple_xattr_set_limited() and simple_xattr_add() functions now handle allocation when xattrs is NULL. simple_xattrs_free() now also frees the xattrs structure itself and sets the pointer to NULL. This simplifies callers and removes the need for most callers to explicitly manage xattrs allocation and lifetime. In shmem_initxattrs(), the total required space for all initial xattrs (ispace) is pre-calculated and deducted from sbinfo->free_ispace. Since this patch modifies the function to add new xattrs directly to the inode's &info->xattrs list rather than using a local temporary variable, a failure means that the partially populated info->xattrs list remains attached to the inode. When the VFS caller handles the -ENOMEM error, it drops the newly created inode via iput(), shmem_free_inode() adds freed to sbinfo->free_ispace a second time, permanently inflating the tmpfs free space quota. Fix by substracting already added xattrs from ispace. Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260605135322.2632068-4-mszeredi@redhat.com Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: 1e7cd8a53b72 ("simpe_xattr: use per-sb cache") Signed-off-by: Sasha Levin commit 23f9cb9762127033456c09edd02eeaa008d2be26 Author: Miklos Szeredi Date: Fri Jun 5 15:53:17 2026 +0200 tmpfs: simplify constructing "security.foo" xattr names [ Upstream commit 832f4de4c8ba4f19e5df1d016a09917204b17834 ] Use kasprintf() instead of doing it with kmalloc() + 2 x memcpy(). Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260605135322.2632068-3-mszeredi@redhat.com Tested-by: Calum Mackay Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: 1e7cd8a53b72 ("simpe_xattr: use per-sb cache") Signed-off-by: Sasha Levin commit bf53db51359939755084d08156684ed649489592 Author: Miklos Szeredi Date: Fri Jun 5 15:53:16 2026 +0200 kernfs: fix xattr race condition with multiple superblocks [ Upstream commit 6a07814ff643b5c8e1353d8c6229f52fde205cde ] Multiple superblocks with different namespaces can share the same kernfs_node when kernfs_test_super() finds a matching root but different namespace. This means multiple inodes from different superblocks can reference the same kernfs_node->iattr->xattrs structure. The VFS layer only holds per-inode locks during xattr operations, which is insufficient to serialize concurrent xattr modifications on the shared kernfs_node. This can lead to race conditions in simple_xattr_set() where the lookup->replace/remove sequence is not atomic with respect to operations from other superblocks. Fix this by protecting xattr operations with the existing hashed kernfs_locks->open_file_mutex[] array, which is already used to protect per-node open file data. The hashed mutex array provides scalable per-node serialization (scaled by CPU count, up to 1024 locks on 32+ CPU systems) with zero memory overhead. Changes: - Rename open_file_mutex[] to node_mutex[] to reflect dual purpose - Add kernfs_node_lock_ptr() and kernfs_node_lock() helpers - Protect simple_xattr_set() calls in kernfs_xattr_set() and kernfs_vfs_user_xattr_set() with the hashed mutex - Update file.c to use new helpers via compatibility wrappers - Update documentation to explain the extended lock usage Fixes: b32c4a213698 ("xattr: add rhashtable-based simple_xattr infrastructure") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260601162454.2116375-1-mszeredi%40redhat.com Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260605135322.2632068-2-mszeredi@redhat.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit d9bcfadd0a3b71fa21f14b413d00c1840788203a Author: Leon Hwang Date: Tue Jun 2 23:09:30 2026 +0800 bpf: Update transport_header when encapsulating UDP tunnel in lwt [ Upstream commit 82d7d0adbc678064543e9d254864f6b4ea4a388c ] Currently, bpf_lwt_push_ip_encap() does not update skb->transport_header. When a driver, e.g. ice, reuses the stale skb->transport_header to offload checksum computation to NIC hardware, VxLAN packets encapsulated by bpf_lwt_push_encap() helper may be dropped due to incorrect checksum. Update skb->transport_header in bpf_lwt_push_ip_encap() whenever the encapsulated packet uses UDP, so checksum offload works correctly. Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap") Cc: Leon Hwang Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260602150931.49629-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 068532141d1740ec5e9da518fb8dc34b44a44bb1 Author: Leon Hwang Date: Fri Jun 5 23:52:48 2026 +0800 bpf: Check tail zero of bpf_prog_info [ Upstream commit 786be2b05980a5828e67fc564ad7517e2adbe9bd ] Since there're 4 bytes padding at the end of struct bpf_prog_info, they won't be checked by bpf_check_uarg_tail_zero(). pahole -C bpf_prog_info ./vmlinux struct bpf_prog_info { ... __u32 attach_btf_obj_id; /* 220 4 */ __u32 attach_btf_id; /* 224 4 */ /* size: 232, cachelines: 4, members: 38 */ /* sum members: 224 */ /* sum bitfield members: 1 bits, bit holes: 1, sum bit holes: 31 bits */ /* padding: 4 */ /* forced alignments: 9 */ /* last cacheline: 40 bytes */ } __attribute__((__aligned__(8))); If a future kernel extension adds a new 4-byte field, older userspace programs allocating this structure on the stack might inadvertently pass uninitialized stack garbage into the new field, permanently breaking backward compatibility. -- sashiko [1] Fix it by changing sizeof(info) to offsetofend(struct bpf_prog_info, attach_btf_id). And, add "__u32 :32" to the tail of struct bpf_prog_info. [1] https://lore.kernel.org/bpf/20260513224823.6494FC19425@smtp.kernel.org/ Fixes: aba64c7da983 ("bpf: Add verified_insns to bpf_prog_info and fdinfo") Acked-by: Mykyta Yatsenko Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260605155249.20772-3-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 41d82064c43e3db0756ae3a9d4c7315b36a34568 Author: Leon Hwang Date: Fri Jun 5 23:52:47 2026 +0800 bpf: Check tail zero of bpf_map_info [ Upstream commit e2a49fdb1beed150125b4104c90eb2a96ec7f63a ] Since there're 4 bytes padding at the end of struct bpf_map_info, they won't be checked by bpf_check_uarg_tail_zero(). pahole -C bpf_map_info ./vmlinux struct bpf_map_info { ... __u64 hash __attribute__((__aligned__(8))); /* 88 8 */ __u32 hash_size; /* 96 4 */ /* size: 104, cachelines: 2, members: 18 */ /* padding: 4 */ /* forced alignments: 1 */ /* last cacheline: 40 bytes */ } __attribute__((__aligned__(8))); If a future kernel extension adds a new 4-byte field, older userspace programs allocating this structure on the stack might inadvertently pass uninitialized stack garbage into the new field, permanently breaking backward compatibility. -- sashiko [1] Fix it by changing sizeof(info) to offsetofend(struct bpf_map_info, hash_size). And, add "__u32 :32" to the tail of struct bpf_map_info. [1] https://lore.kernel.org/bpf/20260513224823.6494FC19425@smtp.kernel.org/ Fixes: ea2e6467ac36 ("bpf: Return hashes of maps in BPF_OBJ_GET_INFO_BY_FD") Acked-by: Mykyta Yatsenko Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260605155249.20772-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 574612793bed416f6c05fe7c9b50e9eb0441997e Author: Kaitao Cheng Date: Fri Jun 5 17:41:43 2026 +0800 bpf: Clear rb node linkage when freeing bpf_rb_root [ Upstream commit 4a7910ee060d8ce55612f5b3cc267f3a265a3cec ] bpf_rb_root_free() detaches the root by copying the current rb_root_cached and then replacing the live root with RB_ROOT_CACHED. It then walks the copied root and drops each object contained in the tree. This leaves the rb node state intact while dropping the object. If the object is refcounted and survives the drop, its bpf_rb_node_kern still contains an owner pointer to the freed root and stale rb tree linkage. If a later bpf_rb_root allocation reuses the same address, bpf_rbtree_remove() can incorrectly pass the owner check and call rb_erase_cached() on a node whose rb pointers belong to the old tree. Mirror the list draining behavior by marking nodes as busy while the root is being detached, then clear the rb node and release the owner before dropping the containing object. This makes surviving nodes unowned and safe to reject from remove or accept for a later add. Fixes: 9c395c1b99bd ("bpf: Add basic bpf_rb_{root,node} support") Signed-off-by: Kaitao Cheng Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260605094143.5509-1-kaitao.cheng@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 865d18a9697792476e83474f7de82084a1db82ce Author: Mykyta Yatsenko Date: Wed Jun 3 07:39:15 2026 -0700 selftests/bpf: Fix flaky file_reader test [ Upstream commit aa22d619ba22177f430693cf5e9495052d996644 ] file_reader/on_open_expect_fault test expects page fault when reading pages from the test harness executable. It is not guaranteed that those are paged out, even after madvise(MADV_PAGEOUT). Relax the condition in the test to succeed with both 0 and -EFAULT returned. Fixes: 784cdf931543 ("selftests/bpf: add file dynptr tests") Reported-by: Shung-Hsi Yu Closes: https://lore.kernel.org/all/ah6g7JSYOWGp2oAG@u94a/ Signed-off-by: Mykyta Yatsenko Tested-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260603-file_reader_flake-v1-1-7f3f52d1e388@meta.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b6cf763eee0a932792bef64ceaca568d324192fc Author: Bernard Metzler Date: Thu Jun 4 18:08:08 2026 +0200 RDMA/siw: Fix endpoint/socket association handling [ Upstream commit ea4f6f6c53577fb3f05dbd78b15e586772d49831 ] Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed. Fixes: 6c52fdc244b5c ("rdma/siw: connection management") Link: https://patch.msgid.link/r/20260604160808.30948-1-bernard.metzler@linux.dev Reported-by: Shuangpeng Bai Signed-off-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 482d6ab0c3ef34f5fe66816e00c6f5ea860da229 Author: Nora Schiffer Date: Tue Feb 24 16:25:23 2026 +0100 arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc aliases [ Upstream commit 08886fa69c0f56f886b63d7835da0632ea4082f7 ] All modern TQ-Systems boards follow the convention that mmc0 is the eMMC and mmc1 is the SD-card when both interfaces exist, reducing differences between boards for both documentation and U-Boot code (which uses the same Device Trees). Adjust the recently added MBLS1028A Device Tree accordingly. Fixes: 0538ca1f102d ("arm64: dts: ls1028a: Add mbls1028a and mbls1028a-ind devicetrees") Signed-off-by: Nora Schiffer Reviewed-by: Alexander Stein Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4e7a828f32d491f294ef09d6c66c184f3e214b20 Author: Frieder Schrempf Date: Thu May 28 12:15:56 2026 +0200 arm64: dts: imx8mp-kontron: Fix GPIO for display power switch [ Upstream commit 5b19ca527471903920d713bc48518a036a95bf6b ] The GPIO that controls the power supply for the LVDS display connector has changed between early prototypes and the current production design of the hardware. Reflect this change in the devicetree to properly switch on the panel supply. This was working before even with the wrong GPIO due to the bidirectional level shifter used on the board which drives the EN signal high even when the input has a (weak) pull down configured as reset condition of the SoC pad. As a result the display was working but the supply was always on. Tested on BL i.MX8MP to show the correct voltage level on the level shifter input. Fixes: 946ab10e3f40 ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit bd75d5a3a2f9eb6b60777df9763a77879db4c861 Author: Alexander Stein Date: Tue Jun 2 11:33:30 2026 +0200 arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as well [ Upstream commit 748835fcb2eb2120234aef9556d282272501b96b ] With deferrable card binding the sound card driver tries to get the mclk configuration before it is setup in sai3 node. Fix this by setting the sai clock config for the audio codec as well. Fixes: d8f9d8126582 ("arm64: dts: imx8mp: Add analog audio output on i.MX8MP TQMa8MPxL/MBa8MPxL") Signed-off-by: Alexander Stein Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 68f788d842ab8e6bc02b7ed88a22ef665040278e Author: Josua Mayer Date: Sun May 24 16:54:41 2026 +0200 arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi [ Upstream commit 13a37b30e464503515625ba891018aec0264c7d2 ] LX2160A and LX2162A are different packages of the same silicon. While LX2160A had two revisions, LX2162A was released later based on LX2160A revision 2. Commit a8fe6c8dfc40 ("arm64: dts: fsl-lx2160a: add rev2 support") has added a new soc dtsi for revision 2. Update LX2162A Clearfog description to use revision 2 dtsi. Fixes: 5093b190f9ce ("arm64: dts: freescale: Add support for LX2162 SoM & Clearfog Board") # no-stable Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6a42df755d4880e473bfc97521dcb8fe9f5b4ef4 Author: Richard Zhu Date: Wed May 20 15:22:28 2026 +0800 arm64: dts: imx95: Correct PCIe outbound address space configuration [ Upstream commit dbecf38e60d4ef08c59836b7bc16e8efca01fc47 ] Fix the PCIe outbound memory ranges for both pcie0 and pcie1 controllers on i.MX95. The memory window size was incorrectly set to 256MB during initial bring-up, but the hardware supports up to 4GB of outbound address space per controller. Additionally, the ECAM region cannot be mapped as I/O space. Use a memory-mapped region for I/O space instead, and relocate the 1MB I/O region to immediately follow the memory region at offset 0xf0000000 within each window. Update the outbound address space layout per controller as follows: - 3.5GB 64-bit prefetchable memory - 256MB 32-bit non-prefetchable memory - 1MB I/O Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support") Signed-off-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit a339b9b8fef59a56ef6e69c5f97262f0851f62e1 Author: Alice Guo Date: Tue May 19 18:55:15 2026 +0800 arm64: dts: imx94: fix DDR PMU interrupt number [ Upstream commit 2521addd5df7e8ab805622d4a0eff9735a45fa11 ] The DDR Performance Monitor node was added with incorrect interrupt number 91, which actually belongs to the wdog4 watchdog. Fix it to the correct interrupt number 374. Fixes: e918e5f847b3 ("arm64: dts: imx94: add DDR Perf Monitor node") Signed-off-by: Alice Guo Reviewed-by: Xu Yang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 531b3ef6ba5bfa6e1e095f0680a76eb8386e9bfe Author: Frieder Schrempf Date: Wed May 13 15:25:31 2026 +0200 arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency [ Upstream commit 95f5bc1632ab8f243e517357b5da0dd28d1c6c92 ] There is an onboard level shifter for the SPI signals that causes additional propagation delay and renders the SPI transmission unreliable at 20 MHz. Reduce the clock frequency to a safe value. Fixes: 946ab10e3f40 ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 98066a34a00a461e8f275d48d53b5341e2ecd94d Author: Jacob Moroni Date: Thu Jun 4 15:41:04 2026 +0000 RDMA/irdma: Initialize iwmr->access during MR registration [ Upstream commit 1521d560b7a1a39e437d37fffd9b55435d329ad1 ] Initialize iwmr->access during initial user mem registration so that it contains a valid value during a subsequent rereg_mr. Otherwise, a rereg_mr that doesn't set IB_MR_REREG_ACCESS (for example, one that only changes the PD) ends up clearing the access flags in HW since iwmr->access is zero-initialized, which is not intended. Fixes: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") Link: https://patch.msgid.link/r/20260604154104.4035581-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d5aa82da8f65562da996d184686db9d0ea718b91 Author: Jacob Moroni Date: Tue Jun 2 21:44:23 2026 +0000 RDMA/irdma: Fix OOB read during CQ MR registration [ Upstream commit 4385ddd654d90245eeb83b3cb539670ab5c85ba4 ] Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://patch.msgid.link/r/20260602214423.1315105-2-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9bd249b7564622838dae684b4f17d207aff39d2e Author: Oliver Hartkopp Date: Fri May 29 17:23:59 2026 +0200 ALSA: hda: fix Kconfig dependency of HD Audio PCI [ Upstream commit 1516134cb65526aba5319bb446c296fc8a192f84 ] With commit 2d9223d2d64c ("ALSA: hda: Move controller drivers into sound/hda/controllers directory") the HD Audio drivers have been moved from linux/sound/pci/hda to linux/sound/hda. But the Kconfig dependency for SND_HDA_INTEL stayed on SND_PCI instead of depending on PCI directly. To make the "HD Audio PCI" configuration entry visible it is currently needed to enable "PCI sound devices" although no PCI device in the submenu needs to be selected. Make SND_HDA_INTEL directly depending on hardware/architecture like the other entries in this Kconfig. Fixes: 2d9223d2d64c ("ALSA: hda: Move controller drivers into sound/hda/controllers directory") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260529-hda-kconfig-v1-1-4a2c6a0efd56@hartkopp.net Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8c1a8248466d34e35ff4c008c36411615230fdd5 Author: Jason Gunthorpe Date: Tue Jun 2 16:37:28 2026 -0300 IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path() [ Upstream commit 9b2207bc5cdb955bdae34b3eec80f04979e17081 ] Codex pointed out that cm_init_av_by_path() can call cm_set_av_port() which takes a reference on the cm device, but then can immediately return error if ib_init_ah_attr_from_path() fails. Since callers like ib_send_cm_req() put the av on the stack this leaks that cm device reference. Re-order cm_init_av_by_path() so it doesn't touch the av until it has done all its failable work, and then update the av in one shot so it is either left alone or fully init'd. Sashiko also pointed out that the cm_destroy_av() prior to cm_init_av_by_path() is harmful as it leaves the AV broken in the error case and thus the REJ won't send. Since cm_init_av_by_path() is now atomic it is safe to delete the cm_destroy_av(). On succees the av from cm_init_av_for_response() is cleaned up by cm_init_av_by_path(), on failure the 'goto rejected' guarentees the av is destroyed during ib_destroy_cm_id(). Fixes: 76039ac9095f ("IB/cm: Protect cm_dev, cm_ports and mad_agent with kref and lock") Link: https://patch.msgid.link/r/0-v1-38292501f539+14f-ib_cm_av_leak_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e5ca5e93586ec865aedccd47bd660a1172bb3058 Author: Arnd Bergmann Date: Tue Jun 2 16:04:34 2026 +0200 RDMA/hfi1: Open-code rvt_set_ibdev_name() [ Upstream commit 0ee8ac903e5aa100a70bef8d0afc19a336ffa775 ] clang warns about a function missing a printf attribute: include/rdma/rdma_vt.h:457:47: error: diagnostic behavior may be improved by adding the 'format(printf, 2, 3)' attribute to the declaration of 'rvt_set_ibdev_name' [-Werror,-Wmissing-format-attribute] 447 | static inline void rvt_set_ibdev_name(struct rvt_dev_info *rdi, | __attribute__((format(printf, 2, 3))) 448 | const char *fmt, const char *name, 449 | const int unit) The helper was originally added as an abstraction for the hfi1 and qib drivers needing the same thing, but now qib is gone, and hfi1 is the only remaining user of rdma_vt. Avoid the warning and allow the compiler to check the format string by open-coding the helper and directly assigning the device name. Fixes: 5084c8ff21f2 ("IB/{rdmavt, hfi1, qib}: Self determine driver name") Link: https://patch.msgid.link/r/20260602140453.3542427-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ebd4575be3878954ade9948db1fe7fd2ef93bc95 Author: DaeMyung Kang Date: Sun May 24 14:42:37 2026 +0900 ntfs: free link name from ntfs_name_cache [ Upstream commit 8488c4d066e6a52937fa5d82ab131c7554ddc9d8 ] ntfs_link() converts the new link name with ntfs_nlstoucs() using NTFS_MAX_NAME_LEN. In this case ntfs_nlstoucs() allocates the result from ntfs_name_cache, and its contract requires callers to release the buffer with kmem_cache_free(ntfs_name_cache, ...). All other ntfs_nlstoucs() callers in namei.c do that, but ntfs_link() uses kfree(), which mismatches the allocator for successfully converted names. The conversion failure path reaches the common out label with uname == NULL. That was harmless for kfree(), but kmem_cache_free() does not provide the same NULL contract. Return directly on conversion failure and free successful conversions with ntfs_name_cache. Fixes: af0db57d4293 ("ntfs: update inode operations") Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f0384658eed1d2bc762b3e68b97990ef7d8f8592 Author: Pablo Neira Ayuso Date: Thu Jun 4 08:21:13 2026 +0200 netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper is pptp [ Upstream commit b0f02608fbcd607b5131cceb91fc0a035264e61c ] For GRE flows, validate that the ct master helper (if any) is pptp before calling nf_ct_gre_keymap_destroy(), so the helper data area can be accessed safely. Note that only the pptp helper provides a .destroy callback. Fixes: e56894356f60 ("netfilter: conntrack: remove l4proto destroy hook") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a052a94bcc629acaecc2ce42a4af77f8fa399757 Author: Pablo Neira Ayuso Date: Thu Jun 4 08:21:12 2026 +0200 netfilter: conntrack: revert ct extension genid infrastructure [ Upstream commit 35e21a4dccc5c255ba59ccfbfeb4629ed21da972 ] This infrastructure is not used anymore after moving ct timeout and helper to use datapath refcount to track object use. Revert commit c56716c69ce1 ("netfilter: extensions: introduce extension genid count") this patch disables all ct extensions (leading to NULL) for unconfirmed conntracks, when this is only targeted at ct helper and ct timeout. There is also codebase that dereferences the ct extension without checking for NULL which could lead to crash. Fixes: c56716c69ce1 ("netfilter: extensions: introduce extension genid count") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8974e226ae04a78be8c565bb42c36ba7289efdb6 Author: Junxiao Chang Date: Sat Jun 6 10:15:14 2026 +0800 x86/cpu: Remove obsolete aperfmperf_get_khz() declaration [ Upstream commit a5f28da54f36f1a8b289d9bdd3e780b2ede0da6f ] aperfmperf_get_khz() was replaced by arch_freq_get_on_cpu(). The remaining declaration in the header file is no longer used and should be removed. Fixes: f3eca381bd49 ("x86/aperfmperf: Replace arch_freq_get_on_cpu()") Signed-off-by: Junxiao Chang Signed-off-by: Ingo Molnar Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260606021514.1433619-1-junxiao.chang@intel.com Signed-off-by: Sasha Levin commit 6e01f23cb087b777442b33931c642d98336dfea0 Author: Shengming Hu Date: Thu Jun 4 20:27:32 2026 +0800 mm/slub: preserve original size in _kmalloc_nolock_noprof retry path [ Upstream commit 19b206b9534a85266efa78febeb4ae185e75bccd ] _kmalloc_nolock_noprof() retries from the next kmalloc bucket when the initial allocation fails. The retry currently reuses `size` as the bucket selector and overwrites it with s->object_size + 1. That value is later passed as the original allocation size to __slab_alloc_node(), slab_post_alloc_hook() and kasan_kmalloc(). On a successful retry this makes KASAN/slub-debug observe the retry bucket selector rather than the caller requested size, potentially widening the valid kmalloc range and hiding overflows. Keep the caller requested size separately as orig_size and pass it to the allocation/debug/KASAN paths. Continue using `size` as the retry cache selector. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock()") Signed-off-by: Shengming Hu Reviewed-by: Harry Yoo (Oracle) Reviewed-by: Hao Li Link: https://patch.msgid.link/202606042027323804pk3MRY42Jy7y42OHAhQZ@zte.com.cn Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Sasha Levin commit 58a4ad9bf636c7f6d747a0f77c00ddcd9ea909b4 Author: Cássio Gabriel Date: Fri Jun 5 01:14:40 2026 -0300 ALSA: usb-audio: qcom: Initialize offload control return value [ Upstream commit 2b5632d72fca0841bea283da2e3a478d24118508 ] snd_usb_offload_create_ctl() returns ret after walking the USB PCM list, but ret is only assigned after a playback stream passes the endpoint and PCM-index filters. If all playback streams are skipped, for example because there is no playback endpoint or because all PCM indexes exceed the 0xff control range, the function returns an uninitialized stack value. Initialize ret to 0 so the no-control-created path returns deterministic success, while preserving the existing negative error return when snd_ctl_add() fails. Fixes: a67656f011d1 ("ALSA: usb-audio: qcom: Add USB offload route kcontrol") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260605-alsa-usb-qcom-offload-ret-init-v1-1-dc72fcc4bd3b@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9aeb0dcfeb460d33d61d434148b51103ab1d2013 Author: Pablo Neira Ayuso Date: Thu Jun 4 08:21:08 2026 +0200 netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount [ Upstream commit 7d6a9cdb8d3a51d9cfe546a09a518ab3d2671549 ] Add a refcount for struct nf_ct_timeout which is used by ct extension to set the custom ct timeout policy, this tells us that the ct timeout is being used by a conntrack entry. When the last conntrack entry drops the refcount on the ct timeout, the ct timeout is released. Remove the refcount for control plane which controls if the ruleset refers to the timeout policy. After this update, it is possible to remove the ct timeout policy from nfnetlink_cttimeout immediately. This is for simplicity not to handle two refcounts on a single object. Remove nf_queue_nf_hook_drop(): a packet sitting in nfqueue will just hold a reference to the nf_ct_timeout object until packet is reinjected, since this is part of the ct extension, this will be released by the time the conntrack is freed. nf_ct_untimeout() is still called to clean up in a best effort basis: the ct timeout on existing entries gets removed when the ct timeout goes away, but as long as the iptables ruleset still refers to the ct timeout through a template, new conntracks may keep attaching it and extend its lifetime until the rule is removed. nf_ct_untimeout() is not called anymore from module removal path, this is unlikely to find timeouts give module refcount is bumped, and the new refcount already tracks the ct timeout policy use so it is released when unused. Fixes: 50978462300f ("netfilter: add cttimeout infrastructure for fine timeout tuning") Fixes: 7e0b2b57f01d ("netfilter: nft_ct: add ct timeout support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 087adcfef920e07d4116339b84c3daf57ec5b751 Author: Fernando Fernandez Mancera Date: Tue May 26 23:58:30 2026 +0200 netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock [ Upstream commit 9e37388b8070afe73d4ab2d973b28593ed65f3ad ] nf_ct_seqadj_init() is called without holding the ct lock. This can race with nf_ct_seq_adjust() when a connection is in CLOSE state due to an RST or connection reopening. In addition for SYN_RECV state, concurrent processing of packets can trigger nf_ct_seq_adjust() too. These situations create a read/write data race. As synproxy is the only user of nf_ct_seqadj_init() at the moment, fix this by holding ct->lock inside nf_ct_seqadj_init() until all is done. Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ea3d2caa5bfacf5db5c1cad521ca5d9144edd9a7 Author: Fernando Fernandez Mancera Date: Tue May 26 23:58:29 2026 +0200 netfilter: synproxy: fix unaligned memory access in timestamp adjustment [ Upstream commit 992c20bc8a4aba220c8b95b467d049289778dad6 ] Use get_unaligned_be32() and put_unaligned_be32() to safely read and write the timestamp fields. This prevents performance degradation due to unaligned memory access or even a crash on strict alignment architectures. This follows the implementation of timestamp parsing in the networking stack at tcp_parse_options() and synproxy_parse_options(). Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a4ff6e76c56b7b97bffec1d296a7a2b363197fa2 Author: Fernando Fernandez Mancera Date: Tue May 26 23:58:28 2026 +0200 netfilter: synproxy: adjust duplicate timestamp options [ Upstream commit 22bb132cfb9b94847d52d73614284b8c5ea8d36e ] RFC 9293 does not mention anything about duplicated options and each networking stack handles it in their own way. Currently, Linux kernel is processing options sequentially and in case of duplicated timestamp options, the value from the latest one overrides the others. As SYNPROXY is modifying only the first timestamp option found, a packet can reach the backend server and it might parse the wrong timestamp value. Let's just continue parsing the following options and in case a duplicated timestamp is found, adjust it too. Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 819fb408d9c930ec383e86a6e6d670ccacea576b Author: Fernando Fernandez Mancera Date: Tue May 26 23:58:27 2026 +0200 netfilter: synproxy: drop packets if timestamp adjustment fails [ Upstream commit 63d29ee95c4ab5976d660182d2e4733bb4a091d8 ] If a packet was malformed or if skb_ensure_writable() failed, the synproxy_tstamp_adjust() function returned 0 indicating an error but it was ignored on the callers. Make the function return a boolean instead to clarify the result and drop the packet if synproxy_tstamp_adjust() failed due to ENOMEM from skb_ensure_writable(). In addition, if there are malformed options, skip the tstamp update but do not drop the packet as that should be done by the policy directly. Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b7b486f006738e2847f9424359fad70229b3b6de Author: Pablo Neira Ayuso Date: Tue May 26 18:40:44 2026 +0200 netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing helper flags [ Upstream commit f8bf5edf7157984bb8e288c8b04fdb041223b80c ] Conntrack helper flags are accessed from packet and netlink dump path. Concurrent update of userspace helper flags is not possible, because the nfnl_mutex in held on updates. These flags are only used by userspace helpers. Use {READ,WRITE}_ONCE() to access this flags from lockless paths. Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d77ddcb7f75f8f250a8f345ee1857af8f848cce9 Author: Fernando Fernandez Mancera Date: Mon May 25 17:35:54 2026 +0200 netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures [ Upstream commit a625c94144c9b66d32e1f374f909f38db46161c1 ] The MSS calculation in nf_osf_match_one() manually shifts bytes to construct a 16-bit value before passing it to ntohs(). This works on little-endian hosts but it does not work on big-endian as the bytes are being always shifted and set in the same way for all architectures. Use get_unaligned_be16() to fix this on big-endian systems. It also simplifies the code. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d59b76143ca2221ef2f2c2510889fc84c9bda33d Author: Dave Jiang Date: Thu Jun 4 11:01:54 2026 -0700 cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses [ Upstream commit 26aa60e0276272ae61b843a05a91748dcb1130f9 ] PCI config space accessors return positive PCIBIOS_* status codes on failure that are positive integers. Several DVSEC accesses in the CXL core propagated these raw values to callers that test for failure against less than 0. Thus silently misinterpret the return value as success. Convert the positive error values to negative errno values so the checks are correct on error paths. While the chances of a config access failure are low, fix for correctness and to avoid confusion in the future when more DVSEC accesses are added. Fixes: 14d788740774 ("cxl/mem: Consolidate CXL DVSEC Range enumeration in the core") Fixes: ce17ad0d5498 ("cxl: Wait Memory_Info_Valid before access memory related info") Reviewed-by: Richard Cheng Reviewed-by: Jonathan Cameron Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260604180154.1925149-3-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 32e0bf80662c981401de9d2d97fe26541cdb3a15 Author: Dave Jiang Date: Thu Jun 4 11:01:53 2026 -0700 cxl/pci: Fix the incorrect check of pci_read_config_word() return [ Upstream commit 66782cfa0085369e2d8c861042f7c6d43431bdb3 ] pci_read_config_word() returns PCIBIOS_* status on error which are positive values. The check should be for non-zero values to indicate error. Fix cxl_set_mem_enable() to check for non-zero return value instead of negative value. While fixing this, also convert the error to negative errno value when returning on error path. Fixes: 34e37b4c432c ("cxl/port: Enable HDM Capability after validating DVSEC Ranges") Reviewed-by: Richard Cheng Reviewed-by: Jonathan Cameron Reviewed-by: Alison Schofield Assisted-by: Claude:claude-opus-4-8 Link: https://patch.msgid.link/20260604180154.1925149-2-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit f5255516ec7add3a6d5d37853ad5a9a9ddb14305 Author: Ian Bridges Date: Mon Jun 1 13:44:33 2026 -0500 ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent [ Upstream commit 1ec3cca2d8b6b9ff6584ca626d4c8918bbf48d44 ] [BUG] Unlinking a refcounted file whose refcount tree has leaf blocks triggers a fortify panic due to an out-of-bounds write. [CAUSE] When the last leaf block is removed from a refcount tree, ocfs2_remove_refcount_extent() converts the root back to leaf mode with a bulk memset on &rb->rf_records. rf_records sits in an anonymous union with rf_list. rf_list.l_tree_depth aliases rf_records.rl_count, and is 0 for a single-level tree. With rl_count equal to 0, the memset writes past the 16-byte declared size of rf_records, which the fortify checker catches. [FIX] Replace the bulk memset on &rb->rf_records with a correctly-bounded memset on rl_recs[] alone, after setting rl_count to the correct value. Link: https://lore.kernel.org/ah3TESOsEO9j_JLU@dev Fixes: 2f26f58df041 ("ocfs2: annotate flexible array members with __counted_by_le()") Signed-off-by: Ian Bridges Reported-by: syzbot+3ef989aae096b30f1663@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3ef989aae096b30f1663 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a165709d386af36baedba7827c76098ee4009f1e Author: Joseph Qi Date: Mon Jun 1 20:16:18 2026 +0800 ocfs2: fix race between ocfs2_control_install_private() and ocfs2_control_release() [ Upstream commit 57dcfd9049d497c31151787a0696d59f0a98f8e6 ] Move atomic_inc(&ocfs2_control_opened) and the handshake state update inside ocfs2_control_lock to close a race window where ocfs2_control_release() can observe ocfs2_control_opened dropping to zero (resetting ocfs2_control_this_node and running_proto) while ocfs2_control_install_private() is about to bump the counter and mark the connection valid. Link: https://lore.kernel.org/20260601121618.1263346-1-joseph.qi@linux.alibaba.com Fixes: 3cfd4ab6b6b4 ("ocfs2: Add the local node id to the handshake.") Signed-off-by: Joseph Qi Reported-by: Ginger Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a09831214912a1f270663d935613910fafd8d883 Author: Zhang Cen Date: Sun May 31 12:47:14 2026 +0800 ocfs2/dlm: require a ref for locking_state debugfs open [ Upstream commit 03ad858ce8064861ea580021976dc19b7aabb549 ] debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Link: https://lore.kernel.org/20260531044714.1640172-1-rollkingzzc@gmail.com Fixes: 4e3d24ed1a12 ("ocfs2/dlm: Dumps the lockres' into a debugfs file") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2c13e02592b918be7725ab5965e01ef4e46c4b57 Author: Zhang Cen Date: Thu May 28 23:12:47 2026 +0800 ocfs2: reject FITRIM ranges shorter than a cluster [ Upstream commit ca1afd88f5eaaff9168e1466e5401385edf59543 ] ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk. Link: https://lore.kernel.org/20260528151247.361854-1-rollkingzzc@gmail.com Fixes: aa89762c5480 ("ocfs2: return EINVAL if the given range to discard is less than block size") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f9e2cb692b77a679b1f4cc2b7b277fa908586533 Author: Zhang Cen Date: Thu May 28 23:12:30 2026 +0800 ocfs2: validate fast symlink target during inode read [ Upstream commit e234973f286ed2e8961a24561ec91594ec3e3ff8 ] ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Link: https://lore.kernel.org/20260528151230.361127-1-rollkingzzc@gmail.com Fixes: ea022dfb3c2a ("ocfs: simplify symlink handling") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Reviewed-by: Joseph Qi Cc: Gui-Dong Han <2045gemini@gmail.com> Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9e7a057934cdd58e4cc94350bcfe5367bbee0f8e Author: Dmitry Antipov Date: Fri May 29 12:41:28 2026 +0300 ocfs2: fix buffer head management in ocfs2_read_blocks() [ Upstream commit 6371a07148ee979af22a9d6f4c277462953a9a4a ] In ocfs2_read_blocks(), caller should't assume that buffer head returned by 'sb_getblk()' is exclusively owned and so 'put_bh()' always drops b_count from 1 to 0. If it is not so, buffer head remains on hold and likely to be returned by the next call to 'sb_getblk()' unchanged - that is, with BH_Uptodate bit set even if it has failed validation previously, thus allowing to insert that buffer head into OCFS2 metadata cache and submit it to upper layers. To avoid such a scenario, BH_Uptodate should be cleared immediately after 'validate()' callback has detected some data inconsistency. Link: https://lore.kernel.org/20260529094128.494293-1-dmantipov@yandex.ru Fixes: cf76c78595ca ("ocfs2: don't put and assigning null to bh allocated outside") Signed-off-by: Dmitry Antipov Reported-by: syzbot+caacd220635a9cc3bac9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=caacd220635a9cc3bac9 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8a3188f3e39bd3cd59deb4d765000705e6e8701a Author: Thomas Weißschuh Date: Tue May 26 18:43:40 2026 +0200 lib: kunit_iov_iter: repeatedly call alloc_pages_bulk() [ Upstream commit 9ac9a08e4ac4bc063e56e1aff266c5e8aa5c6c03 ] alloc_pages_bulk() is not guaranteed to return all requested pages in a single call. Call it repeatedly until all pages have been allocated or no more progress is being made. Link: https://lore.kernel.org/20260526-kunit_iov_iter-alloc_bulk-v2-1-24fbcd995c61@weissschuh.net Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator") Signed-off-by: Thomas Weißschuh Cc: "Christian A. Ehrhardt" Reviewed-by: Andrew Morton Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 610a0d2a35496738e1472fb0f318d5008a1c634f Author: Zhang Cen Date: Mon May 25 12:17:26 2026 +0800 ocfs2: rebase copied fsdlm LVB pointers in locking_state [ Upstream commit 93612d48fa42b3d1a637eb9279e15281c611c000 ] The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Link: https://lore.kernel.org/20260525041726.4112882-1-rollkingzzc@gmail.com Fixes: cf4d8d75d8ab ("ocfs2: add fsdlm to stackglue") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cbd3102fe27bc87da244bf4c3ba670ea4698b0a8 Author: Wandun Chen Date: Thu Jun 4 09:53:32 2026 +0800 of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails [ Upstream commit e1686ca81dbf3edbde589b7daf312b45cbf76e03 ] The global pointer 'reserved_mem' continues to reference the reserved_mem_array which lives in __initdata if alloc_reserved_mem_array() fails. of_reserved_mem_lookup() is exported for post-init use, that would dereference freed memory and trigger a use-after-free. So reset reserved_mem_count to 0 when alloc_reserved_mem_array() fails. Fixes: 00c9a452a235 ("of: reserved_mem: Add code to dynamically allocate reserved_mem array") Signed-off-by: Wandun Chen Link: https://patch.msgid.link/20260604015332.3669384-1-chenwandun1@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit b5fc19c898e08deb40b671329d99d85d2d575f0b Author: Alex Deucher Date: Wed May 6 16:50:42 2026 -0400 drm/amdkfd: always resume_all after suspend_all [ Upstream commit 56ae73c92e200e630c2bdf1e98c88b86c8483b37 ] Need to restore any good queues even if the suspend_all failed for some. Always run remove_queue as that will schedule a GPU reset is removing the queue fails. v2: move resume_all after remove Fixes: eb067d65c33e ("drm/amdkfd: Update BadOpcode Interrupt handling with MES") Reviewed-by: Amber Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 36b1d997866f6083d33934983aa2ce0a184ed642 Author: Alexei Starovoitov Date: Thu May 28 15:20:14 2026 -0700 bpf: Take mmap_lock in zap_pages() [ Upstream commit 80b89d0226a05e8b67969de99c31b51fcd54f76a ] zap_vma_range() requires the owning mm's mmap_lock to be held. Taking mmap_read_lock under arena->lock would AB-BA against arena_vm_close() and arena_map_mmap(), both of which run with mmap_write_lock held and then acquire arena->lock. Instead drop arena->lock, mmget_not_zero() the vma's mm, take mmap_read_lock, and re-resolve the vma via find_vma() since it may have been unmapped or replaced while waiting. Track processed vmls with a per-call generation in vml->zap_gen and serialize zap_pages() callers with a new arena->zap_mutex so concurrent callers on different uaddr ranges do not mark each other's vmls processed before the zap is done. Reported-by: David Hildenbrand Fixes: 317460317a02 ("bpf: Introduce bpf_arena.") Signed-off-by: Alexei Starovoitov Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260528222014.38980-1-alexei.starovoitov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8c4f27a7f364eab514d2fa55c11f39d505122f1b Author: Dan Williams Date: Tue May 19 15:12:04 2026 -0700 cxl/test: Fix __fortify_panic [ Upstream commit 08326b92c7a414a73b5b308d1daf0e91e0134dfc ] Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it is potentially overflowing the xormaps array per __counted_by(nr_maps). Quiet the false positive by initializing @nr_maps earlier. memcpy: detected buffer overflow: 32 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728 Call Trace: __fortify_panic+0xd/0xf setup_xor_mapping+0x6c/0xa0 [cxl_translate] [ dj: Fixed up @nr_entries to @nr_maps in commit log. ] Fixes: 06377c54a133 ("cxl/test: Add cxl_translate module for address translation testing") Signed-off-by: Dan Williams Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260519221204.1517773-3-djbw@kernel.org Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 18c67ecc5dafe14055edcea53f36f4e31df1816b Author: Dan Williams Date: Tue May 19 15:12:03 2026 -0700 cxl/fwctl: Fix __fortify_panic [ Upstream commit 6c9d2e87df40d606f1c85143e9acb1ecff463d5e ] Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core] Fixes: 4d1c09cef2c2 ("cxl: Add support for fwctl RPC command to enable CXL feature commands") Signed-off-by: Dan Williams Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260519221204.1517773-2-djbw@kernel.org Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit ff9748200698e9641f41ba922ffef728167807c2 Author: Andreas Kemnade Date: Thu Jun 4 12:33:16 2026 +0200 wifi: wlcore: enable the right set of ciphers [ Upstream commit 7495adaa0e45e180f4b6b7436675c6266edff1ff ] The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess. Fixes: c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") Signed-off-by: Andreas Kemnade Link: https://patch.msgid.link/20260604103316.377251-1-andreas@kemnade.info Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 28c812b62b405e9bb78ae410a3692eb352b90b7f Author: Antony Antony Date: Tue May 26 21:07:01 2026 +0200 xfrm: fix NAT-related field inheritance in SA migration [ Upstream commit 364e165e0b63e8142e76de83e96ae8e36c3b955a ] During SA migration via xfrm_state_clone_and_setup(), nat_keepalive_interval was silently dropped and never copied to the new SA. mapping_maxage was unconditionally copied even when migrating to a non-encapsulated SA. Both fields are only meaningful when UDP encapsulation (NAT-T) is in use. Move mapping_maxage and add nat_keepalive_interval inside the existing if (encap) block, so both are inherited when migrating with encapsulation and correctly absent when migrating without it. Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states") Reviewed-by: Sabrina Dubroca Signed-off-by: Antony Antony Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit c18ad83ae58e6422e3927b2405d47d1fe65b24bb Author: Sandipan Das Date: Mon Jun 1 17:43:05 2026 +0530 perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains [ Upstream commit 67d27727854def4a7e2b386429941f5c4741ccc4 ] For DF and UMC PMUs, a single context is shared across all CPUs that are connected to the same Data Fabric (DF) instance. Currently, the Package ID, which also happens to be the Socket ID, is used to identify DF instances. This approach works for configurations having a single IO Die (IOD) but fails in the following cases. * Older Zen 1 processors, where each chiplet has its own DF instance. * Any configurations with multiple DF instances or multiple IODs in the same package. The correct way to identify DF instances is through the Node ID (not to be confused with NUMA Node ID). This is available in ECX[7:0] of CPUID leaf 0x8000001e and returned via topology_amd_node_id(). Hence, replace usage of topology_logical_package_id() with topology_amd_node_id(). Fixes: 07888daa056e ("perf/x86/amd/uncore: Move discovery and registration") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/e7a71a727c6a7b118c23d3e469929c538c4665aa.1780315832.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit 734a4b17e655d1705eb818da6df180a8fdf29db2 Author: Zide Chen Date: Tue Jun 2 07:49:04 2026 -0700 perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery [ Upstream commit 81ec618f59415bdcf3e8989e2691c1f240be27fb ] pci_get_domain_bus_and_slot() increments the reference count of the returned PCI device and therefore requires a matching pci_dev_put(). In skx_upi_topology_cb() and discover_upi_topology(), the lookup is performed inside a loop, but pci_dev_put() is only called once after the loop. As a result, references from all previous iterations are leaked. Move pci_dev_put(dev) into the if (dev) block immediately after upi_fill_topology() returns. Opportunistically, fix uninitialized variable in skx_upi_topology_cb(). Fixes: 4cfce57fa42d ("perf/x86/intel/uncore: Enable UPI topology discovery for Skylake Server") Fixes: f680b6e6062e ("perf/x86/intel/uncore: Enable UPI topology discovery for Icelake Server") Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260602144908.263680-4-zide.chen@intel.com Signed-off-by: Sasha Levin commit a2bc4e61b011df2c9e0c8f1fa5277f3584ec3f60 Author: Zide Chen Date: Tue Jun 2 07:49:02 2026 -0700 perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems [ Upstream commit 63f48abd55d0417996bca86022925c853a2b436b ] In uncore_find_add_unit(), PMON units with the same unit ID may be added to the uncore discovery RB-tree for different dies. These units are distinguished by node->die. However, intel_generic_uncore_box_ctl() uses a fixed die ID of -1 when looking up the discovery unit, which may retrieve the wrong node on multi-die systems. Use box->dieid instead so the correct discovery unit is selected. No functional issue has been observed so far because currently supported platforms happen to use the same unit control register for such units. Remove WARN_ON_ONCE() because with the above change a NULL unit can be expected, e.g. when a CPU die is offline during uncore enumeration and the unit is not added to the RB-tree. In this case, intel_uncore_find_discovery_unit() returns NULL once the die becomes online, and it is expected that the PMU box is not functional for that die. Fixes: b1d9ea2e1ca4 ("perf/x86/uncore: Apply the unit control RB tree to MSR uncore units") Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260602144908.263680-2-zide.chen@intel.com Signed-off-by: Sasha Levin commit 7bab94272fa4374459aaa219de5b8b4beecab2cb Author: Sandipan Das Date: Mon Jun 1 20:28:46 2026 +0530 perf/x86/amd/core: Always use the NMI latency mitigation [ Upstream commit 73a4c02f94a98d94480c3e5c81450215a4da05ba ] Commit df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp") fixed handling of late-arriving NMIs but limited the mitigation to processors having X86_FEATURE_PERFCTR_CORE. However, it is unclear if processors without this feature are also affected. When Mediated vPMU is enabled on affected hardware, it is also possible to bypass the fix inside KVM guests if X86_FEATURE_PERFCTR_CORE is removed from the guest CPUID (e.g. using "-cpu host,-perfctr-core" with QEMU). Hence, use the mitigation at all times. Fixes: df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/29a3c970da289ab8f24282933bdb36545c0403e8.1780325517.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit f10a7a4266a4332bd86d8642edba18e8c97694ce Author: Christian Brauner Date: Fri Apr 24 15:46:45 2026 +0200 eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers [ Upstream commit 0dcb726466a556f273beaadfb76f12d1b0087dd7 ] ep->ovflist and epi->next both use EP_UNACTIVE_PTR (a cast to (void *)-1) as a sentinel, with distinct meanings at each site: ep->ovflist == EP_UNACTIVE_PTR no scan in progress epi->next == EP_UNACTIVE_PTR epi not on ovflist Call sites had to know the sentinel's value and, by convention, what it meant in each context. Hide both behind inline helpers: ep_is_scanning(ep) predicate for "scan in progress" ep_enter_scan(ep) WRITE_ONCE flip to NULL (scan start) ep_exit_scan(ep) WRITE_ONCE flip to sentinel (scan end) epi_on_ovflist(epi) predicate for "epi is on ovflist" epi_clear_ovflist(epi) clear epi's ovflist link slot Convert ep_events_available(), ep_start_scan(), ep_done_scan(), ep_poll_callback(), and ep_alloc_epitem() to use the wrappers. The ovflist state-machine transitions are now named, not encoded in sentinel comparisons, and the top-of-file "Ready-list state machine" section is the single place that spells out the sentinel's meaning. ep_alloc() keeps the raw "ep->ovflist = EP_UNACTIVE_PTR" init (no concurrent access at that point) with an inline "not scanning" comment, and the tfile_check_list sentinel is left alone -- it will disappear entirely when the loop-check globals move into a stack-allocated ep_ctl_ctx in a later commit. Also rework ep_done_scan()'s for-loop: the combined initializer + update clause that advanced nepi AND cleared epi->next in one step was clever but hard to read; splitting the update into two statements inside the body makes the epi_clear_ovflist() call visible. No functional change. Signed-off-by: Christian Brauner (Amutable) Link: https://patch.msgid.link/20260424-work-epoll-rework-v1-14-249ed00a20f3@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit 85b4e4824de72b6ba6b7cca6ee81a7169a0185c0 Author: Christian Brauner Date: Fri Apr 24 15:46:43 2026 +0200 eventpoll: extract ep_deliver_event() from ep_send_events() [ Upstream commit 499a5e7f4a57fa08a297c627d007a55069acac9a ] ep_send_events()'s body covered two concerns: per-item work (PM wakeup-source bookkeeping, re-poll, copy_to_user, level-trigger re-queue, EPOLLONESHOT mask clear) and the scan-level accumulator (maxevents cap, EFAULT preservation, txlist/rdllist splice). Extract the per-item work as ep_deliver_event(), which returns a tri-state int: 1 one event was delivered; caller advances the counter, 0 re-poll produced no caller-requested events (item drops out of the ready list; a future callback will re-queue), -EFAULT copy_to_user() faulted; item is already re-inserted at the head of the txlist so ep_done_scan() splices it back to rdllist. The per-item comments (PM ordering, the "sole writer to rdllist" invariant for the LT re-queue, the EFAULT semantics) move into ep_deliver_event(). ep_send_events() reduces to the fatal-signal short-circuit, scan bracket, and a short txlist walk that accumulates the deliveries and preserves the "first error wins" EFAULT contract (res = delivered only if no event was previously delivered; otherwise the success count is returned and -EFAULT is reported on the next call). No functional change. Signed-off-by: Christian Brauner (Amutable) Link: https://patch.msgid.link/20260424-work-epoll-rework-v1-12-249ed00a20f3@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit e30ab826f7c981b4e4b35c507e5fde77ece3efd8 Author: Christian Brauner Date: Fri Apr 24 15:46:41 2026 +0200 eventpoll: split ep_insert() into alloc + register stages [ Upstream commit e0e35f4cb983a55a36e79e9b2a20ca0e0688fae6 ] ep_insert() was 130 lines and mixed four concerns in one body: user quota charge and epitem allocation, attach-into-file-hlist plus rbtree insert plus target-ep locking, reverse-path + EPOLLWAKEUP + poll-queue install with rollback, and ready-list publication. Factor the first two concerns into named helpers so the body reduces to orchestration. ep_alloc_epitem() charges the user's epoll_watches quota, allocates a fresh epitem, and initializes its fields. On failure it returns ERR_PTR(-ENOSPC) or ERR_PTR(-ENOMEM); on success the epi is not yet linked into anything. ep_register_epitem() installs @epi into @tfile's f_ep hlist and @ep's rbtree, optionally chains @tfile onto tfile_check_list for the path check, takes the tep->mtx nested lock for the epoll-watches- epoll case, and finally takes the ep_get() reference that pairs with ep_remove()'s ep_put() in ep_insert()'s error paths. On failure it frees the epi and decrements epoll_watches to match ep_alloc_epitem(). ep_insert()'s remaining body is the rollback-via-ep_remove() chain (reverse_path_check, EPOLLWAKEUP source creation, ep_ptable_queue_proc allocation) and the ready-list / wake publication. Remove a few stale comments that duplicated function-level documentation or described obvious code. No functional change; rollback boundaries unchanged -- every error path after ep_register_epitem() still calls ep_remove(), preserving the ep->refcount invariant that keeps ep_remove()'s WARN_ON_ONCE safe. Signed-off-by: Christian Brauner (Amutable) Link: https://patch.msgid.link/20260424-work-epoll-rework-v1-10-249ed00a20f3@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit 0fcf81fc5f01a4fb88cab0e4ded79cee09ceecad Author: Christian Brauner Date: Fri Apr 24 15:46:39 2026 +0200 eventpoll: rename attach_epitem() to ep_attach_file() [ Upstream commit 6a3f1a494bc91d7976cf0d2b200bb3f1a22eef64 ] ep_remove_file() tears down the f_ep linkage that attach_epitem() establishes, so the pair should look like one. Rename to ep_attach_file() for the "ep_*" + subject symmetry and to match the naming used elsewhere in the file (ep_insert, ep_modify, ep_remove, ep_remove_file, ep_remove_epi, ep_unregister_pollwait). Pure rename; no functional change. Signed-off-by: Christian Brauner (Amutable) Link: https://patch.msgid.link/20260424-work-epoll-rework-v1-8-249ed00a20f3@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit 8e3788d9605ecc3b8290ce822644b9c7647052ee Author: Jeff Layton Date: Mon May 11 07:58:27 2026 -0400 mm: preserve PG_dropbehind flag during folio split [ Upstream commit 0ad186cf167fdbeb6b29a8005c71973781036bd3 ] __split_folio_to_order() copies page flags from the original folio to newly created sub-folios using an explicit allowlist, but PG_dropbehind is not included. When a large folio with PG_dropbehind set is split, only the head sub-folio retains the flag; all tail sub-folios silently lose it and will not be reclaimed eagerly after writeback completes. Add PG_dropbehind to the flag copy mask so that the drop-behind hint is preserved across folio splits. Fixes: a323281cdfec ("mm: add PG_dropbehind folio flag") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260511-dontcache-v7-1-2848ddce8090@kernel.org Acked-by: David Hildenbrand (Arm) Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit d16923a45d4d08367650fdc3451c89299ab6ac5a Author: Pranjal Shrivastava Date: Thu Jun 4 14:03:10 2026 +0800 iommu/vt-d: Fix RB-tree corruption in probe error path [ Upstream commit 43bd9e6d5513cb1edbafdeef146a1edc3aaced56 ] The info->node RB-tree member is zero-initialized via kzalloc. If a device does not support ATS, the device_rbtree_insert() call is skipped. If a subsequent probe step fails, the error path jumps to device_rbtree_remove(), which misinterprets the zeroed node as a tree root and corrupts the device RB-tree. Fix this by explicitly initializing the RB-node as empty using RB_CLEAR_NODE() during initialization and guarding the removal with RB_EMPTY_NODE(). Fixes: 4f1492efb495 ("iommu/vt-d: Revert ATS timing change to fix boot failure") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260525205628.CD4431F000E9@smtp.kernel.org/ Suggested-by: Baolu Lu Signed-off-by: Pranjal Shrivastava Link: https://lore.kernel.org/r/20260531170254.60493-2-praan@google.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a9326b652bc7acd748d7a1143573845c7924d847 Author: Michael S. Tsirkin Date: Mon Mar 2 03:51:49 2026 -0500 vhost: fix vhost_get_avail_idx for a non empty ring [ Upstream commit 09861858a68342f851f71c669ac0f69865c32151 ] vhost_get_avail_idx is supposed to report whether it has updated vq->avail_idx. Instead, it returns whether all entries have been consumed, which is usually the same. But not always - in drivers/vhost/net.c and when mergeable buffers have been enabled, the driver checks whether the combined entries are big enough to store an incoming packet. If not, the driver re-enables notifications with available entries still in the ring. The incorrect return value from vhost_get_avail_idx propagates through vhost_enable_notify and causes the host to livelock if the guest is not making progress, as vhost will immediately disable notifications and retry using the available entries. This goes back to commit d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") which changed vhost_enable_notify() to compare the freshly read avail index against vq->last_avail_idx instead of the previously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move smp_rmb() into vhost_get_avail_idx()") then carried over the same comparison when refactoring vhost_enable_notify() to call the unified vhost_get_avail_idx(). The obvious fix is to make vhost_get_avail_idx do what the comment says it does and report whether new entries have been added. Reported-by: ShuangYu Fixes: d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") Cc: Stefan Hajnoczi Acked-by: Jason Wang Reviewed-by: Stefano Garzarella Signed-off-by: Michael S. Tsirkin Message-Id: <559b04ae6ce52973c535dc47e461638b7f4c3d63.1772441455.git.mst@redhat.com> Signed-off-by: Sasha Levin commit cfec9afb8a80a37c975cc96fb7b4cf5dd3f670c7 Author: Woojin Ji Date: Wed Jun 3 09:33:39 2026 +0900 bpftool: Use libbpf error code for flow dissector query [ Upstream commit 8a7f2bff2165e53595d1e91c160b340f978c0ab7 ] bpf_prog_query() returns a negative errno on failure. query_flow_dissector() currently closes the namespace fd and then reads errno to decide whether -EINVAL means that the running kernel does not support flow dissector queries. That errno check controls behavior, not just diagnostics: -EINVAL is handled as a non-fatal old-kernel case, while any other error makes bpftool net fail. The namespace fd is opened read-only, so close() is not expected to commonly fail in normal use. Still, the BPF_PROG_QUERY error is already available in err, and reading errno after an intervening close() is fragile. If close() does change errno, the compatibility branch may be based on close()'s error instead of the BPF_PROG_QUERY result. This was reproduced with an LD_PRELOAD fault injector that forced BPF_PROG_QUERY for BPF_FLOW_DISSECTOR to fail with EINVAL and then forced close() on the netns fd to fail with EIO. The unpatched bpftool reported "can't query prog: Input/output error". With this change, the same injected failure is handled as the intended non-fatal EINVAL compatibility case. Use the libbpf-returned error code instead. Keep the existing errno reset in the non-fatal path to preserve batch mode behavior. The success path is unchanged. Fixes: 7f0c57fec80f ("bpftool: show flow_dissector attachment status") Signed-off-by: Woojin Ji Signed-off-by: Andrii Nakryiko Acked-by: Leon Hwang Acked-by: Yonghong Song Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260603003339.33791-1-random6.xyz@gmail.com Assisted-by: ChatGPT:gpt-5.5 Signed-off-by: Sasha Levin commit b6bbac4856fe34d0bf6fc139e21db88109f77841 Author: Lizhi Hou Date: Fri May 29 09:21:22 2026 -0700 accel/amdxdna: Return errors for failed debug BO commands [ Upstream commit 62c1671f6454ceaa80e9ceff63f821aa36f35154 ] The config and sync debug BO commands currently may report success even when the operation fails. Capture the firmware return status and propagate the corresponding error to userspace. Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260529162122.1976376-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit be576a522cda35b2dd70dd0f1909193fb060b851 Author: Yunxiang Li Date: Mon Jun 1 15:15:06 2026 -0400 drm/amdgpu: set sub_block_index for mca ras sub-blocks [ Upstream commit baa286df5fb366e4aee5b747443dfc7194fdaa59 ] The mca ras sub-blocks (mp0, mp1, mpio) all share the AMDGPU_RAS_BLOCK__MCA block id and are distinguished only by sub_block_index. The ras manager object for an mca block is selected with: con->objs[AMDGPU_RAS_BLOCK__LAST + head->sub_block_index] Since the rework in commit 7f544c5488cf ("drm/amdgpu: Rework mca ras sw_init") moved the ras_comm setup into amdgpu_mca_mp*_ras_sw_init() but left sub_block_index unset, mp0/mp1/mpio all default to index 0 and collide on the same object slot. mp0 grabs the slot and creates its sysfs node first; mp1 (and mpio) then find the slot already in use, so amdgpu_ras_block_late_init() -> amdgpu_ras_sysfs_create() returns -EINVAL: amdgpu: mca.mp1 failed to execute ras_block_late_init_default! ret:-22 amdgpu: amdgpu_ras_late_init failed -22 amdgpu: amdgpu_device_ip_late_init failed amdgpu: Fatal error during GPU init The error is currently masked because amdgpu_ras_late_init() does not check the return value of amdgpu_ras_block_late_init_default(), but it already leaves mp1/mpio without their sysfs nodes and becomes a fatal init failure as soon as that return value is honored. Restore the per-sub-block sub_block_index assignment so each mca sub-block maps to its own object slot. Fixes: 7f544c5488cf ("drm/amdgpu: Rework mca ras sw_init") Signed-off-by: Yunxiang Li Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f85750e0f87730bca937fd22bbf4905c1b4d2975 Author: Vitaly Prosyak Date: Thu Apr 23 19:44:33 2026 -0400 drm/amd/pm: Add empty string validation to sysfs store functions [ Upstream commit c872fc05380c4eb2761ab289ce6a215c9bfa9576 ] Discovery: Fuzzing for secure supply chain requirements Tool: amd_fuzzing_sysfs (IGT test) The AMDGPU power management sysfs store functions accept whitespace-only strings when they should reject them with -EINVAL. This was discovered via systematic fuzzing of sysfs interfaces crossing the user/kernel trust boundary. Affected functions: - amdgpu_set_power_dpm_force_performance_level (power_dpm_force_performance_level) - amdgpu_set_power_dpm_state (power_dpm_state) - amdgpu_set_pp_power_profile_mode (pp_power_profile_mode) - amdgpu_read_mask (used by pp_dpm_sclk/mclk/fclk/socclk/pcie) - amdgpu_set_pp_features (pp_features) Impact: - Whitespace-only writes (e.g., "\n", " ") can cause unexpected behavior - Better input validation at user/kernel trust boundary - Defense-in-depth improvement Root Cause: The sysfs_streq() function matches whitespace-only strings against empty string, allowing invalid input to be processed. Fix: Add explicit validation at the start of each affected store function: if (count == 0 || sysfs_streq(buf, "")) return -EINVAL; This rejects whitespace-only inputs before they are processed. Note that write() calls with count=0 (truly empty strings) are handled by the VFS layer before reaching the sysfs .store() callback - the VFS returns 0 (success) without calling the kernel function. This is POSIX-compliant behavior and cannot be changed at the kernel driver level. What This Patch Fixes: - Whitespace-only strings: "\n", " ", " ", etc. are now rejected - Defense-in-depth: Explicit validation at trust boundary - Code clarity: Intent to reject invalid input is explicit What This Patch Cannot Fix: - write(fd, "", 0) returning success - this is VFS layer behavior - Fuzzer tests for empty strings (count=0) will still report "accepted" because the VFS handles this before the kernel callback Test Results After Fix: - Whitespace strings ("\n", " ") now properly rejected - Empty string tests (count=0) still show as "accepted" due to VFS behavior - Overall improvement in input validation robustness - No impact on valid inputs This is a defense-in-depth improvement that hardens input validation even though VFS layer behavior prevents catching all edge cases. Tested: amd_fuzzing_sysfs IGT test Cc: Christian König Cc: Alex Deucher Cc: Jesse Zhang Signed-off-by: Vitaly Prosyak Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit efb1dadaeb897b22b9e118d398d0f41e70e9ccca Author: Vitaly Prosyak Date: Thu May 14 18:55:42 2026 -0400 drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump [ Upstream commit 08ac3a7879d300302a1927ce2038629539a37f8b ] The ring content dump in amdgpu_coredump() uses two separate loops over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffers. Both loops use the same condition to skip rings: atomic_read(&ring->fence_drv.last_seq) == ring->fence_drv.sync_seq Because last_seq is an atomic that is updated concurrently by the fence signalling path, additional rings may appear unsignalled in the second loop that were signalled during the first. When this happens, idx exceeds the allocated ring_count and the store to coredump->rings[idx] writes past the end of the kcalloc-ed buffer. This was found during IGT stressful test amd_queue_reset which triggers random GPU resets. The OVERSIZE subtest (CMD_STREAM_EXEC_INVALID_PACKET_LENGTH_OVERSIZE on GFX ring) provokes a ring timeout and subsequent coredump, which hits the race between the counting and copying loops. The failure is non-deterministic and depends on fence signalling timing during the reset. KASAN log: BUG: KASAN: slab-out-of-bounds in amdgpu_coredump+0x1274/0x12f0 [amdgpu] Write of size 4 at addr ffff888106154258 by task kworker/u128:5/23625 CPU: 16 UID: 0 PID: 23625 Comm: kworker/u128:5 Not tainted 6.19.0+ #35 Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] Call Trace: dump_stack_lvl+0xa5/0x110 print_report+0xd1/0x660 kasan_report+0xf3/0x130 __asan_report_store4_noabort+0x17/0x30 amdgpu_coredump+0x1274/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] drm_sched_job_timedout+0x194/0x5c0 [gpu_sched] process_one_work+0x84b/0x1990 worker_thread+0x6b8/0x11b0 Allocated by task 23625: kasan_save_stack+0x39/0x70 __kasan_kmalloc+0xc3/0xd0 __kmalloc_noprof+0x2ec/0x910 amdgpu_coredump+0x5c5/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] The buggy address belongs to the object at ffff888106154200 which belongs to the cache kmalloc-rnd-09-96 of size 96 The buggy address is located 16 bytes to the right of allocated 72-byte region [ffff888106154200, ffff888106154248) 72 bytes = 3 * sizeof(struct amdgpu_coredump_ring), so ring_count was 3 but idx reached 3+, writing ring_index (at struct offset 16) 16 bytes past the allocation. Fix by adding an idx < ring_count guard to the copy loop so it cannot exceed the allocated count even when the fence state changes between the two passes. Fixes: eea85914d15b (drm/amdgpu: save ring content before resetting the device) Cc: Pierre-Eric Pelloux-Prayer Cc: Christian König Cc: Alex Deucher Signed-off-by: Vitaly Prosyak Reviewed-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e4ee9d5b3226906179217be8625717b8a5c9541e Author: Marek Szyprowski Date: Fri May 22 08:10:12 2026 +0200 irqchip/exynos-combiner: Remove useless spinlock [ Upstream commit 6fe450074626eaab3def4b3e8c1819d46d2d682c ] irq_controller_lock doesn't protect anything, it is a leftover from early development or copy/paste. Remove it completely. Fixes: 96031b31a4b3 ("irqchip/exynos-combiner: Switch to raw_spinlock") Suggested-by: Thomas Gleixner Suggested-by: Sebastian Andrzej Siewior Signed-off-by: Marek Szyprowski Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Peter Griffin Link: https://lore.kernel.org/all/20260521090453.bbUZ00tS@linutronix.de Link: https://patch.msgid.link/20260522061012.2687122-1-m.szyprowski@samsung.com/ Signed-off-by: Sasha Levin commit d06df6e447a8510f86db44b2522d5375362a9499 Author: Li Chen Date: Wed May 13 16:58:17 2026 +0800 ext4: fix fast commit wait/wake bit mapping on 64-bit [ Upstream commit 8b3bc93fee6771775243665a0cf31857d6659775 ] On 64-bit, ext4 dynamic inode states live in the upper half of i_flags, and ext4_test_inode_state() applies the corresponding +32 offset. The fast-commit wait and wake paths open-coded the wait key with the raw EXT4_STATE_* value. Add small helpers for the state wait word and bit, and use them for the FC_COMMITTING and FC_FLUSHING_DATA waits so the wait key follows the same mapping as the state helpers. Fixes: 857d32f26181 ("ext4: rework fast commit commit path") Reported-by: Sashiko AI review Signed-off-by: Li Chen Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260513085818.552432-1-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0cfc9b30ebe6a650a1b98d1bc9c633115ed63dac Author: Karl Mehltretter Date: Sat May 23 20:51:23 2026 +0200 lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT [ Upstream commit 06961d60a0e410bf8df69ccff7eb1bd824912b8f ] The WW-mutex selftests deliberately exercise failing lock paths. On PREEMPT_RT, some of those paths enter the RT-mutex scheduler helpers. The change referenced by the Fixes tag made those helpers track RT-mutex scheduling state in current->sched_rt_mutex. The bit is normally cleared by the matching post-schedule helper, but some WW-mutex selftests disable the runtime debug_locks flag before that happens. With debug_locks cleared, lockdep_assert() does not evaluate the expression that clears the bit, leaving stale state for the next testcase. With CONFIG_PREEMPT_RT=y and CONFIG_DEBUG_LOCKING_API_SELFTESTS=y, that stale state produces warnings such as: WARNING: kernel/sched/core.c:7557 at rt_mutex_pre_schedule+0x26/0x2d RIP: 0010:rt_mutex_pre_schedule+0x26/0x2d Save and restore current->sched_rt_mutex around each testcase, matching the existing PREEMPT_RT cleanup for task-local migration and RCU state. Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") Assisted-by: Codex:gpt-5 Signed-off-by: Karl Mehltretter Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260523185123.17482-3-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit e87d8a7d86ce9a337a6ce5035cb5be141f0685ad Author: Karl Mehltretter Date: Sat May 23 20:51:22 2026 +0200 lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT [ Upstream commit d8c897b20bf4d4cbb1e935a8ceb666bcc0f82580 ] The lockdep selftests deliberately run unbalanced locking patterns. dotest() restores the task state they leave behind before running the next testcase. On PREEMPT_RT, spin_lock() uses migrate_disable() instead of disabling preemption. dotest() cleans up the resulting migration-disabled state, but that cleanup is still guarded by CONFIG_SMP. That used to match the scheduler data model, where migration_disabled was also CONFIG_SMP-only. The commit referenced below made SMP scheduler state unconditional, so CONFIG_SMP=n PREEMPT_RT kernels with CONFIG_DEBUG_LOCKING_API_SELFTESTS=y report success from the selftests and then trip over stale current->migration_disabled state: releasing a pinned lock bad: scheduling from the idle thread! Kernel panic - not syncing: Fatal exception Save and restore current->migration_disabled for every PREEMPT_RT build. Fixes: cac5cefbade9 ("sched/smp: Make SMP unconditional") Assisted-by: Codex:gpt-5 Signed-off-by: Karl Mehltretter Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260523185123.17482-2-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit 57088b06109f3222963c639d8d743f42c2899b13 Author: Al Viro Date: Tue May 12 00:29:37 2026 -0400 configfs_lookup(): don't leave ->s_dentry dangling on failure [ Upstream commit 10da12d352b7b2bb330a8609fdda9a58bf0e9856 ] Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so... Fixes: 3d0f89bb1694 ("configfs: Add permission and ownership to configfs objects") # 2.6.16-rc3 Reviewed-by: Jan Kara Reviewed-by: Breno Leitao Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 24084f7d239b5416c1241ee901a06c0df88073f8 Author: Inochi Amaoto Date: Sun Apr 26 09:34:49 2026 +0800 riscv: dts: sophgo: sg2042: use hex for CPU unit address [ Upstream commit a7e658907686528fe06a11828b04a3e42df9ef18 ] Previous the CPU unit address cpu of sg2042 use decimal, it is not following the general convention for unit addresses of the OF. Convent the unit address to hex to resolve this problem. The introduces a small change for the CPU node name, but it should affect nothing since there is no direct full-path reference to these CPU nodes. Fixes: ae5bac370ed4 ("riscv: dts: sophgo: Add initial device tree of Sophgo SRD3-10") Tested-by: Chen Wang # Pioneerbox. Reviewed-by: Guo Ren Reviewed-by: Chen Wang Acked-by: Conor Dooley Tested-by: Chen Wang on Pioneerbox. Link: https://patch.msgid.link/20260426013449.694435-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto Signed-off-by: Chen Wang Signed-off-by: Sasha Levin commit 9c1099b5c68d6ec9d7e4ffbb7847ecec8196184f Author: Inochi Amaoto Date: Sun Apr 26 09:34:48 2026 +0800 riscv: dts: sophgo: sg2044: use hex for CPU unit address [ Upstream commit 207cbc477406a72952e27ace2eadbae55164f129 ] Previous the CPU unit address cpu of sg2044 use decimal, it is not following the general convention for unit addresses of the OF. Convent the unit address to hex to resolve this problem. The introduces a small change for the CPU node name, but it should nothing since there is no direct full-path reference to these CPU nodes. Fixes: 967a94a92aaa ("riscv: dts: add initial Sophgo SG2042 SoC device tree") Reviewed-by: Chen Wang Reviewed-by: Guo Ren Link: https://patch.msgid.link/20260426013449.694435-2-inochiama@gmail.com Signed-off-by: Inochi Amaoto Signed-off-by: Chen Wang Signed-off-by: Sasha Levin commit 61a8ae8eb5222ea5b1d1662d778637599dd31177 Author: Alexander Potapenko Date: Mon May 4 12:06:37 2026 +0200 lib/test_meminit: use && for bools [ Upstream commit 8e0c2085c978ed6d9764d79fc785920360096f21 ] As pointed out by Dan Carpenter, test_kmemcache() was using a bitwise AND on two bools instead of a boolean AND. Fix this for the sake of code cleanliness. Link: https://lore.kernel.org/20260504100637.1535762-1-glider@google.com Fixes: 5015a300a522 ("lib: introduce test_meminit module") Signed-off-by: Alexander Potapenko Reported-by: Dan Carpenter Closes: https://lore.kernel.org/kernel-janitors/afOcIan1ap9kD26M@stanley.mountain/ Reviewed-by: Andrew Morton Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 05e6e3ea362bf21cad16f68699bb1cf0fe21052d Author: Frederic Weisbecker Date: Fri May 8 15:16:33 2026 +0200 tick/sched: Fix TOCTOU in nohz idle time fetch [ Upstream commit 86db4084b4b5d1a074bcc66c108a4c9d266812d4 ] When the nohz idle time is fetched, the current clock timestamp is taken outside the seqcount, which can result in a race as reported by Sashiko: get_cpu_sleep_time_us() tick_nohz_start_idle() ----------------------- --------------------- now = ktime_get() write_seqcount_begin(idle_sleeptime_seq); idle_entrytime = ktime_get() tick_sched_flag_set(ts, TS_FLAG_IDLE_ACTIVE); write_seqcount_end(&ts->idle_sleeptime_seq); read_seqcount_begin(idle_sleeptime_seq) delta = now - idle_entrytime); //!! But now < idle_entrytime idle = *sleeptime + delta; read_seqcount_retry(&ts->idle_sleeptime_seq, seq) Here the read side fetches the timestamp before the write side and its update. As a result the time delta computed on the read side is negative (ktime_t is signed) and breaks the cputime monotonicity guarantee. This could possibly be fixed with reading the current clock timestamp inside the seqcount but the reader overhead might then increase. Also simply checking that the current timestamp is above the idle entry time is enough to prevent any issue of the like. Fixes: 620a30fa0bd1 ("timers/nohz: Protect idle/iowait sleep time under seqcount") Reported-by: Sashiko Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260508131647.43868-2-frederic@kernel.org Signed-off-by: Sasha Levin commit c3da741d5b2119c61c4498bc936f0fc1dbc3c79b Author: Daniel Borkmann Date: Tue Jun 2 15:30:49 2026 +0200 bpf: Reject exclusive maps for bpf_map_elem iterators [ Upstream commit 3c56ee343f9412d81918635c3e25e22a5dd6d87e ] Exclusive maps (aka excl_prog_hash) are meant to be reachable only from the single program whose hash matches. This is enforced by check_map_prog_compatibility() when the map is referenced from a program such as signed BPF loaders. A bpf_map_elem iterator, however, binds its target map at attach time in bpf_iter_attach_map() instead of referencing it from the program, so the exclusivity check is never reached. On top of that, the iterator exposes the map value as a writable buffer. Fixes: baefdbdf6812 ("bpf: Implement exclusive map creation") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260602133052.423725-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b174edd29a337ff30cd6c95f28d0809681866740 Author: Nathan Chancellor Date: Mon Jun 1 20:56:31 2026 -0700 driver core: Use system_percpu_wq instead of system_wq [ Upstream commit fda8355f13ea3c0f9499acdeff3024995b474948 ] Commit 1137838865bf ("driver core: Use mod_delayed_work to prevent lost deferred probe work") added a use of system_wq, which is deprecated in favor of system_percpu_wq added by commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq"). An upcoming warning in the workqueue tree flags this with: workqueue: work func deferred_probe_timeout_work_func enqueued on deprecated workqueue. Use system_{percpu|dfl}_wq instead. Switch to system_percpu_wq to clear up the warning. Fixes: 1137838865bf ("driver core: Use mod_delayed_work to prevent lost deferred probe work") Signed-off-by: Nathan Chancellor Reviewed-by: Rafael J. Wysocki (Intel) Link: https://patch.msgid.link/20260601-driver-core-fix-system_wq-warning-v1-1-f9001a70ee25@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 5d0e7d2af884b91329235abb16652ae4eead8079 Author: liuxixin Date: Thu May 28 18:00:01 2026 +0800 nvme: fix FDP fdpcidx bounds check [ Upstream commit 0967074f6830718fd2597404ef119bddd0dbfd00 ] The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1). Fixes: 30b5f20bb2dd ("nvme: register fdp parameters with the block layer") Reviewed-by: Nitesh Shetty Reviewed-by: Christoph Hellwig Signed-off-by: liuxixin Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 4e3ed2dabf6fb7c5deb8b6278add473fdd2de9af Author: Guanyou.Chen Date: Fri May 22 21:09:59 2026 +0800 sched: restore timer_slack_ns when resetting RT policy on fork [ Upstream commit 63c1a12bc0e09af7dee919c4fb4a300a719d5125 ] Commit ed4fb6d7ef68 ("hrtimer: Use and report correct timerslack values for realtime tasks") sets timer_slack_ns to 0 for RT tasks in __setscheduler_params(). However, when an RT task with SCHED_RESET_ON_FORK creates child threads, the children inherit timer_slack_ns=0 from the parent. sched_fork() resets the child's policy to SCHED_NORMAL but does not restore timer_slack_ns, leaving the child permanently running with zero slack. Fix this by restoring timer_slack_ns from default_timer_slack_ns in sched_fork() when resetting from RT/DL to NORMAL policy, matching the existing behavior in __setscheduler_params(). Note: this fix alone requires a correct default_timer_slack_ns to be effective. See the following patch for that fix. Fixes: ed4fb6d7ef68 ("hrtimer: Use and report correct timerslack values for realtime tasks") Reported-by: Qiaoting.Lin Signed-off-by: Guanyou.Chen Signed-off-by: Chunhui.Li Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260522131000.1664983-2-chenguanyou@xiaomi.com Signed-off-by: Sasha Levin commit b6bc07e49a5fbb335f56eb90cd63dec6584c77d3 Author: Danila Chernetsov Date: Sat May 30 12:23:11 2026 +0000 ext2: fix ignored return value of generic_write_sync() [ Upstream commit a4659be0bc7cb1856ffb15b67f903229ae8891ec ] Fix ext2_dio_write_iter() to propagate the error returned by generic_write_sync() instead of silently discarding it, which could cause write(2) to return success to userspace on O_SYNC/O_DSYNC files even when the sync failed. The correct pattern, already used in ext2_dax_write_iter() in the same file and in ext4, xfs, f2fs among others, is: if (ret > 0) ret = generic_write_sync(iocb, ret); Found by Linux Verification Center (linuxtesting.org) with SVACE. [JK: Reflect also filemap_write_and_wait() return value] Fixes: fb5de4358e1a ("ext2: Move direct-io to use iomap") Signed-off-by: Danila Chernetsov Link: https://patch.msgid.link/20260530122311.136803-1-listdansp@mail.ru Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 96ec62a55b78c313fc51222486125bce8615e345 Author: Sang-Heon Jeon Date: Fri Apr 17 22:58:05 2026 +0900 mm/fake-numa: fix under-allocation detection in uniform split [ Upstream commit 3a3fc1dfd6a958615ebaab8fb251e89fc2b3f2f2 ] When splitting NUMA node uniformly, split_nodes_size_interleave_uniform() returns the next absolute node ID, not the number of nodes created. The existing under-allocation detection logic compares next absolute node ID (ret) and request count (n), which only works when nid starts at 0. For example, on a system with 2 physical NUMA nodes (node 0: 2GB, node 1: 128MB) and numa=fake=8U, 8 fake nodes are successfully created from node 0 and split_nodes_size_interleave_uniform() returns 8. For node 1, fake node nid starts at 8, but only 4 fake nodes are created due to current FAKE_NODE_MIN_SIZE being 32MB, and split_nodes_size_interleave_uniform() returns 12. By existing under-allocation detection logic, "ret < n" (12 < 8) is false, so the under-allocation will not be detected. Fix under-allocation detection logic to compare the number of actually created nodes (ret - nid) against the request count (n). Also skip under-allocation detection logic for memoryless physical nodes where no fake nodes are created. Also, fix the outdated comment describing split_nodes_size_interleave_uniform() to match the actual return value. Signed-off-by: Sang-Heon Jeon Reported-by: Donghyeon Lee Reported-by: Munhui Chae Fixes: cc9aec03e58f ("x86/numa_emulation: Introduce uniform split capability") # 4.19 Link: https://patch.msgid.link/20260417135805.1758378-1-ekffu200098@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 0497ff765746d9b2d17445c8f7cc737b36c0152a Author: Deepanshu Kartikey Date: Tue Jun 2 08:22:49 2026 +0530 bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs [ Upstream commit b93c55b4932dd7e32dca8cf34a3443cc87a02906 ] commit 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning htab with internal structs") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF Fixes: 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning htab with internal structs") Reported-by: syzbot+36e50496c8ac4bcde3f9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=36e50496c8ac4bcde3f9 Suggested-by: Al Viro Link: https://lore.kernel.org/all/20260423043906.GN3518998@ZenIV/ Link: https://lore.kernel.org/all/20260602002607.110866-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Acked-by: Al Viro Link: https://lore.kernel.org/r/20260602025249.113828-1-kartikey406@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a8c524e2daf23ef168d76e54644967868aa546ed Author: Chanwoo Lee Date: Wed May 27 18:21:34 2026 +0900 scsi: ufs: Fix wrong value printed in unexpected UPIU response case [ Upstream commit 2483ae0a56231a915c706411421c6c002a2bf83e ] In ufshcd_transfer_rsp_status(), the default case of the inner switch statement prints the UPIU response code when an unexpected response is received. However, the code was printing 'result' variable which is always 0 at that point, making the error message useless for debugging. Fix this by printing the actual UPIU response code returned by ufshcd_get_req_rsp(). Fixes: 08108d31129a ("scsi: ufs: Improve type safety") Signed-off-by: Chanwoo Lee Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260527092134.275887-1-cw9316.lee@samsung.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1538da12ed88fd8f1272d419992a1309593af39f Author: Dan Carpenter Date: Sat May 30 22:45:48 2026 +0300 scsi: pm8001: Fix error code in non_fatal_log_show() [ Upstream commit 1b6f03b7ae9ee27054c55bb55a69d05555a78516 ] The non_fatal_log_show() function is supposed to return negative error codes on failure. But because the error codes are saved in a u32 and then cast to signed long, they end up being high positive values instead of negative. Remove the intermediary u32 variable to fix this bug. Fixes: dba2cc03b9db ("scsi: pm80xx: sysfs attribute for non fatal dump") Signed-off-by: Dan Carpenter Acked-by: Jack Wang Link: https://patch.msgid.link/ahs-bEsBJH0KhnsX@stanley.mountain Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0777038191f8dcd154611cc13ab5d56313ccf96a Author: Daniel Borkmann Date: Mon Jun 1 17:02:46 2026 +0200 libbpf: Skip max_entries override on signed loaders [ Upstream commit 60214435b365ecdd40b2f96d4e54564b5c927645 ] bpf_gen__map_create() lets the host-supplied loader ctx override a map's max_entries at runtime (map_desc[idx].max_entries, when non-zero). This is how the light skeleton sizes maps to the target machine, but it happens after emit_signature_match() and is covered by neither the signed loader instructions nor the hashed blob. For a signed loader this means an untrusted host can re-dimension the program's maps, outside what the signature attests to. Gate the override on gen_hash so signed loaders use the signer-provided max_entries baked into the blob. Fixes: ea923080c145 ("libbpf: Embed and verify the metadata hash in the loader") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-6-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b544115380a052d45ffc345f07c91755506b7a21 Author: Daniel Borkmann Date: Mon Jun 1 17:02:45 2026 +0200 libbpf: Skip initial_value override on signed loaders [ Upstream commit 61e084152328867fe2279cc790573aae39959cd5 ] bpf_gen__map_update_elem() emits code that, when the host-supplied loader ctx provides a non-NULL map_desc[idx].initial_value, overwrites the blob value with bytes read from the host (bpf_copy_from_user / bpf_probe_read_kernel) before the BPF_MAP_UPDATE_ELEM that populates the program's .data/.rodata/.bss maps. This override runs after emit_signature_match() has validated map->sha[], and initial_value is part of neither the signed loader instructions nor the hashed data blob. For a signed loader this lets an untrusted host substitute global-variable contents into a program whose code carries a valid signature, thus weakening what the signature attests to. The blob already contains the signer-provided value (added via add_data() and covered by the embedded, signed hash), so simply skip emitting the override for signed loaders (gen_hash). Runtime initialization stays available for the unsigned light-skeleton path as before. The jump offsets within the override block are internal to it, so guarding the whole block leaves them unchanged. Fixes: ea923080c145 ("libbpf: Embed and verify the metadata hash in the loader") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-5-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 0dad5adeb34b6f78a883e8faa6a1c947a240e7c9 Author: KP Singh Date: Mon Jun 1 17:02:44 2026 +0200 libbpf: Reject non-exclusive metadata maps in the signed loader [ Upstream commit 0fb6c9ed6493b4af01be8bb0a384574eba7df636 ] The loader verifies map->sha against the metadata hash in its instructions. map->sha is calculated when BPF_OBJ_GET_INFO_BY_FD is called on the frozen map. While the map is frozen, the /signed loader/ must also ensure the map is exclusive, as, without exclusivity (which a hostile host could just omit when loading the loader), another BPF program with map access can mutate the contents afterwards, so the check passes on stale data. With the extra check as part of the signed loader, it now refuses to move on with map->sha validation if the host set it up wrongly. Fixes: fb2b0e290147 ("libbpf: Update light skeleton for signing") Signed-off-by: KP Singh Co-developed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7c58ace08f180f8e249e714d1623388362f9d807 Author: Daniel Borkmann Date: Mon Jun 1 17:02:42 2026 +0200 bpf: Reject exclusive maps as inner maps in map-in-map [ Upstream commit 9a3c3c49c333760c8944dadacbe114c1884546ef ] An exclusive map (created with excl_prog_hash) is bound to a single program by hash: check_map_prog_compatibility() refuses to load any program whose digest does not match map->excl_prog_sha. That check only runs for maps a program references directly, i.e. its used_maps. A map reached at runtime through a map-of-maps is never in used_maps, and bpf_map_meta_equal() does not consider excl_prog_sha, so an exclusive map can be inserted into a non-exclusive outer map and then looked up and mutated by an unrelated program, bypassing the exclusivity guarantee. For the signed loader this defeats the metadata map exclusivity check added in the signed loader: the cached map->sha[] is validated against the signed hash while another program on a hostile host rewrites the frozen map's contents through the outer map. Fixes: baefdbdf6812 ("bpf: Implement exclusive map creation") Reported-by: sashiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1f04d24e4bf134e5115d6a53862511436c6ae2ed Author: Martin Wilck Date: Wed May 13 19:42:36 2026 +0200 scsi: Revert "scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans" [ Upstream commit 8c292e89bd831c8a13e92f3429ef66bbe0b83677 ] This reverts commit 37c4e72b0651e7697eb338cd1fb09feef472cc1a. Said commit causes excessive resource usage and even system freeze with some controllers, e.g. smartpqi and hisi_sas. The justification provided by the patch authors [1] was supporting a special mode of the mpi3mr and mpt3sas, so-called "Tri-mode", in which NVMe drives are exposed as SCSI devices on a separate channel. While that's useful for these drivers, it seems wrong to cause major breakage for other drivers for the sake of this feature. [1] https://lore.kernel.org/linux-scsi/CAFdVvOwjy+2ORJ6uJkspiLTPF05481U7gcS4QohFOFGPqAs8ig@mail.gmail.com/ Fixes: 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans") Signed-off-by: Martin Wilck Cc: Don Brace Cc: storagedev@microchip.com Cc: Ranjan Kumar Cc: Sathya Prakash Veerichetty Cc: Kashyap Desai Cc: Sumit Saxena Cc: mpi3mr-linuxdrv.pdl@broadcom.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: Yihang Li Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260513174236.430465-3-mwilck@suse.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ea03b98f3fc26556ac699a023e2c1e603e875dd8 Author: Neal Cardwell Date: Sun May 31 11:35:57 2026 -0700 tcp_bbr: fix SPDX-License-Identifier to be GPL-2.0 OR BSD-3-Clause [ Upstream commit 4490516d2109e105daf732681435c5c075b5d61b ] Since TCP BBR congestion control was introduced in commit 0f8782ea1497 ("tcp_bbr: add BBR congestion control") it has always been offered as "Dual BSD/GPL": MODULE_LICENSE("Dual BSD/GPL"); A GPL-2.0-only SPDX header was erroneously added in the recent commit 2ed4b46b4fc7 ("net: Add SPDX ids to some source files"). This commit revises the tcp_bbr.c SPDX-License-Identifier to note that this file is licensed as "GPL-2.0 OR BSD-3-Clause". Fixes: 2ed4b46b4fc7 ("net: Add SPDX ids to some source files") Signed-off-by: Neal Cardwell Cc: Yuchung Cheng Cc: Van Jacobson Cc: Soheil Hassas Yeganeh Reviewed-by: Tim Bird Link: https://patch.msgid.link/20260531183558.2337381-1-ncardwell.sw@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4eafa810b042d985ec6bbf5b514414e73cee6f6f Author: Alison Schofield Date: Wed May 27 19:16:22 2026 -0700 nvdimm/btt: Handle preemption in BTT lane acquisition [ Upstream commit 8d4b989d9c9afe5f185aa5853b666fc4617afe9e ] BTT lanes serialize access to per-lane metadata and workspace state during BTT I/O. The btt-check unit test reports data mismatches during BTT writes due to a race in lane acquisition that can lead to silent data corruption. The existing lane model uses a spinlock together with a per-CPU recursion count. That recursion model stopped being valid after BTT lanes became preemptible: another task can run on the same CPU, observe a non-zero recursion count, bypass locking, and use the same lane concurrently. BTT lanes are also held across arena_write_bytes() calls. That path reaches nsio_rw_bytes(), which flushes writes with nvdimm_flush(). Some provider flush callbacks can sleep, making a spinlock the wrong primitive for the lane lifetime. Replace the spinlock-based recursion model with a dynamically allocated per-lane mutex array and take the lane lock unconditionally. Add might_sleep() to catch any future atomic-context caller. Found with the ndctl unit test btt-check.sh. Fixes: 36c75ce3bd29 ("nd_btt: Make BTT lanes preemptible") Assisted-by: Claude-Sonnet:4.5 Tested-by: Aboorva Devarajan Reviewed-by: Aboorva Devarajan Reviewed-by: Vishal Verma Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260528021625.618462-1-alison.schofield@intel.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 6034e3d19b98b3d28a2f55c62182caf460c168cf Author: Randy Dunlap Date: Tue May 19 10:35:26 2026 -0700 x86/cpu: Keep the PROCESSOR_SELECT menu together [ Upstream commit 1df61a8b2d01c560822a0421f2a76af7fda34c1f ] Having a stray kconfig symbol in the middle of the PROCESSOR_SELECT menu (this symbol plus its dependent symbols) causes the menu dependencies not to be displayed correctly in "make {menu,n,g,x}config". Move the BROADCAST_TLB_FLUSH symbol away from the PROCESSOR_SELECT menu so that the list of processors is displayed correctly. Fixes: 767ae437a32d ("x86/mm: Add INVLPGB feature and Kconfig entry") Signed-off-by: Randy Dunlap Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260519173526.10985-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 2cbc214a7917f9294d43b7178d8de6d1596bdd4a Author: Yuho Choi Date: Mon May 25 00:01:58 2026 -0400 ARM: imx31: Fix IIM mapping leak in revision check [ Upstream commit ccb4b54b8ecf1ebafef96d538cd6c5c8455bb390 ] mx31_read_cpu_rev() maps the IIM registers with of_iomap() to read the silicon revision, but returns without unmapping the MMIO mapping. Keep the normalized revision value in a local variable and route the return path through iounmap() after the revision register has been read. Fixes: 3172225d45bd ("ARM: imx31: Retrieve the IIM base address from devicetree") Signed-off-by: Yuho Choi Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit c04e59bcaf6f91f6eefa38a6e7e57ee5a00b44f5 Author: Rafael J. Wysocki Date: Mon Jun 1 18:55:15 2026 +0200 ACPI: button: Fix lid_device value leak past driver removal [ Upstream commit f8600e0d1ac60e6eac34bc9c7e8cf78f7a4c368f ] Static variable lid_device is set when the ACPI button driver probes the last lid device (under the assumptions that there will be only one lid device in the system) and never cleared, but in principle it should be reset when the driver unbinds from the lid device pointed to by it. Address that and add locking that is needed to clear and set that variable safely. Fixes: 7e12715ecc47 ("ACPI button: provide lid status functions") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/6281379.lOV4Wx5bFT@rafael.j.wysocki Signed-off-by: Sasha Levin commit d2306ad238c665d4d39e0aa8b44953c2df60728f Author: Bart Van Assche Date: Thu May 21 10:33:29 2026 -0700 ata: libata: Fix ata_exec_internal() [ Upstream commit aa0ae1c35f7b3e9afed2324bed5f5c87ad55b92c ] Some but not all ata_exec_internal() calls happen from the context of the ATA error handler. Commit c0c362b60e25 ("libata: implement cross-port EH exclusion") added ata_eh_release() and ata_eh_acquire() calls in ata_exec_internal(). Calling these functions is necessary if the caller holds the eh_mutex but is not allowed if the caller doesn't hold that mutex. Fix this by only calling ata_eh_release() and ata_eh_acquire() if the caller holds the eh_mutex. An example of an indirect caller of ata_exec_internal() that does not hold the eh_mutex is ata_host_register(). Fixes: c0c362b60e25 ("libata: implement cross-port EH exclusion") Signed-off-by: Bart Van Assche Reviewed-by: Niklas Cassel Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 5f5be2aa3b6d730c51dd4f8b432f2ad72823e63f Author: Wei Zhang Date: Mon May 11 21:49:05 2026 -0700 wifi: ath12k: fix NULL deref in change_sta_links for unready link [ Upstream commit 47809a7c8348bc4a332ccc26a37c7145a5f609f8 ] _ieee80211_set_active_links() calls _ieee80211_link_use_channel() for each newly-added link and WARN_ON_ONCE()s if it fails. The call uses assign_on_failure=true, which allows mac80211 to continue despite driver failures, but when a mac80211-level channel validation fails (e.g., combinations check, DFS, or no available radio), drv_assign_vif_chanctx() is never reached. Since ath12k_mac_vdev_create() is only called from that path, arvif->is_created remains false and arvif->ar remains NULL for the failed link. The subsequent drv_change_sta_links() call reaches ath12k_mac_op_change_sta_links(), which allocates an arsta and sets ahsta->links_map |= BIT(link_id) for the broken link before checking whether the link is ready. When the vdev was never created, only station_add() is skipped, but the link remains in links_map. Any subsequent operation iterating links_map and dereferencing arvif->ar without a NULL check will crash. Two observed examples are NULL deref in ath12k_mac_ml_station_remove() on disconnect and in ath12k_mac_op_set_key() when wpa_supplicant installs PTK keys. BUG: Unable to handle kernel NULL pointer dereference at 0x00000000 pc : ath12k_mac_station_post_remove+0x40/0xe8 [ath12k] Call trace: ath12k_mac_station_post_remove+0x40/0xe8 [ath12k] ath12k_mac_op_sta_state+0xb60/0x1720 [ath12k] drv_sta_state+0x100/0xbd8 [mac80211] __sta_info_destroy_part2+0x148/0x178 [mac80211] ieee80211_set_disassoc+0x500/0x678 [mac80211] BUG: Unable to handle kernel NULL pointer dereference at 0x00000000 pc : ath12k_mac_op_set_key+0x1f8/0x2c0 [ath12k] Call trace: ath12k_mac_op_set_key+0x1f8/0x2c0 [ath12k] drv_set_key+0x70/0x100 [mac80211] ieee80211_key_enable_hw_accel+0x78/0x260 [mac80211] ieee80211_add_key+0x16c/0x2ac [mac80211] nl80211_new_key+0x138/0x280 [cfg80211] Fix this by checking arvif->is_created before calling ath12k_mac_alloc_assign_link_sta(). This prevents the broken link from entering links_map, so all subsequent operations iterating the bitmap are protected. The reliability of arvif->is_created across all error paths is ensured by the preceding patch. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: a27fa6148dac ("wifi: ath12k: support change_sta_links() mac80211 op") Signed-off-by: Wei Zhang Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260512044906.1735821-3-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e0140e094b196d92f2a4ce167ee73cbfab000290 Author: Wei Zhang Date: Mon May 11 21:49:04 2026 -0700 wifi: ath12k: fix inconsistent arvif state in vdev_create error paths [ Upstream commit c972636efc63f0f43d725b59805dd1ae5bc4b31e ] ath12k_mac_vdev_create() has three error path issues that leave arvif in an inconsistent state: 1. When ath12k_wmi_vdev_create() fails, the function returns directly without clearing arvif->ar, which was already set before the WMI call. Subsequent code checking arvif->ar to determine vdev readiness will see a non-NULL value despite no vdev existing in firmware. 2. When ath12k_wmi_send_peer_delete_cmd() fails in err_peer_del, the code jumped to err: skipping the DP peer cleanup and vdev rollback, leaving num_created_vdevs, vdev maps and arvif list membership live. 3. When ath12k_wait_for_peer_delete_done() fails, the code jumped to err_vdev_del: skipping the DP peer cleanup. Fix by changing the ath12k_wmi_vdev_create() failure to goto err instead of returning directly, routing both err_peer_del failure paths through err_dp_peer_del: for proper DP peer and vdev rollback, and consolidating the arvif state cleanup at err:. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO") Signed-off-by: Wei Zhang Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260512044906.1735821-2-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5187a92099778501f21af76ed6c8415d128e7298 Author: Miaoqing Pan Date: Tue May 12 10:11:08 2026 +0800 wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic() [ Upstream commit 98d4f92ab6a1af2ea2ab590d7e2801b203110981 ] In ath12k_wifi7_dp_rx_h_verify_tkip_mic(), the call to ath12k_dp_rx_check_nwifi_hdr_len_valid() may return false when the NWIFI header length is invalid, causing the function to abort early with -EINVAL. When this happens, the error propagates to ath12k_wifi7_dp_rx_h_defrag(), which clears first_frag by setting it to NULL. As a result, the corresponding MSDU is no longer referenced by the defragmentation path and is never freed. This leads to a memory leak for the affected MSDU on this error path. Proper cleanup is required to ensure the MSDU is released when header validation fails during TKIP MIC verification. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 9a0dddfb30f1 ("wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi") Signed-off-by: Miaoqing Pan Reviewed-by: Tamizh Chelvam Raja Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260512021108.2031651-1-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 6a39b2e950aeca3b62146a4deb66937555f1c772 Author: Kwan Lai Chee Hou Date: Thu May 7 09:53:35 2026 +0800 wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode [ Upstream commit 10085a654a4c2331d5f0cdc20bfc839a49fbb886 ] In monitor mode, the driver incorrectly assigns the legacy rate to the rate_idx field of the radiotap header for HT/VHT/HE/EHT frames, ignoring the actual MCS value parsed from the hardware. This causes packet analyzers (like Wireshark) to display incorrect MCS values (e.g., legacy base rates instead of the true MCS). Fix this by assigning ppdu_info->mcs as the default rate_mcs in ath12k_dp_mon_fill_rx_rate(), and remove rate_idx assignments in ath12k_dp_mon_update_radiotap() to preserve the previously calculated MCS values (including the HT NSS offset). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ Fixes: 5393dcb45209 ("wifi: ath12k: change the status update in the monitor Rx") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220864 Signed-off-by: Kwan Lai Chee Hou Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260507015336.14636-1-laicheehou9@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit eac7ec8a153806bcc7933a9761b779df1dac3457 Author: J. Neuschäfer Date: Thu Mar 26 15:03:48 2026 +0100 HID: wiimote: Fix table layout and whitespace errors [ Upstream commit 12b7731995ca577d86e02196e99ba9c126f47282 ] Some tab characters snuck into the data layout table for turntable extensions, which resulted in the table only looking right at a tabstop of 4, which is uncommon in the kernel. Change them to the equivalent amount of spaces, which should look correct in any editor. While at it, also fix the other whitespace errors (trailing spaces at end of line) introduced in the same commit. Fixes: 05086f3db530b3 ("HID: wiimote: Add support for the DJ Hero turntable") Reviewed-by: David Rheinsberg Signed-off-by: J. Neuschäfer Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 6128c4dede9770c85bcabb72f970dd9f3da65691 Author: Yuho Choi Date: Wed May 13 23:40:04 2026 -0400 ARM: imx3: Fix CCM node reference leak [ Upstream commit 36d46348eb5fc4bc505cd2290ddd70c25fbe6bb3 ] of_find_compatible_node() returns a referenced device node. The i.MX31 and i.MX35 early init paths use the node to map the CCM registers with of_iomap(), but never drop the node reference. Release the node after the mapping is created. Fixes: 2cf98d12958c ("ARM: imx3: Retrieve the CCM base address from devicetree") Signed-off-by: Yuho Choi Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ef2422b9e8bec07f6881349291889409bc0d4160 Author: Chuck Lever Date: Tue Mar 24 11:18:12 2026 -0400 NFSD: Fix delegation reference leak in nfsd4_revoke_states [ Upstream commit 625981c8f3da0cc2d236d7b46c39dd75554b8276 ] When revoking delegation state, nfsd4_revoke_states() takes an extra reference on the stid before calling unhash_delegation_locked(). If unhash_delegation_locked() returns false (the delegation was already unhashed by a concurrent path), dp is set to NULL and revoke_delegation() is skipped, but the extra reference is never released. Each occurrence permanently pins the stid in memory. The leaked reference also prevents nfs4_put_stid() from decrementing cl_admin_revoked, leaving the counter permanently inflated. Drop the extra reference in the failure path. Fixes: 8dd91e8d31fe ("nfsd: fix race between laundromat and free_stateid") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 48ea89e4efaa6e93acfc4b1605efd3df8e0a1fe9 Author: John Madieu Date: Mon May 25 11:02:14 2026 +0000 ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble [ Upstream commit c0758279367e9d82eb7d7b4959718d7d32e96b7d ] RSND_SOC_MASK was defined as (0xFF << 4), spanning bits 4-11. This is wider than needed since only nibble B (bits 7:4) is used for SoC identifiers. Narrow it to (0xF << 4) to match the intended single-nibble allocation and prevent overlap with bits 8-11 which will be used by upcoming RZ series flags. No functional change, since the only current user (RSND_SOC_E) fits within a single nibble. Fixes: ba164a49f8f7 ("ASoC: rsnd: src: Avoid a potential deadlock") Signed-off-by: John Madieu Acked-by: Kuninori Morimoto Link: https://patch.msgid.link/20260525110230.4014435-3-john.madieu.xa@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7a2ac292a070f8d2d0691ad983d9cfd49f5be653 Author: Carlos Song Date: Mon May 25 14:29:28 2026 +0800 spi: imx: replace dmaengine_terminate_all() with dmaengine_terminate_sync() [ Upstream commit 4503b2fe761c2bfd33ed043d9b9deec0d1eb40e0 ] dmaengine_terminate_all() has been deprecated, so replace it with dmaengine_terminate_sync(). Fixes: ba9b28652c75 ("spi: imx: enable DMA mode for target operation") Fixes: a450c8b77f92 ("spi: imx: handle DMA submission errors with dma_submit_error()") Signed-off-by: Carlos Song Link: https://patch.msgid.link/20260525062928.3191821-1-carlos.song@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 422bb0227d2f88a50ee5ea4aae9dc19d0186ac42 Author: Felix Gu Date: Fri May 22 20:40:48 2026 +0800 spi: atmel: fix DMA channel and bounce buffer leaks [ Upstream commit bd7e9843ec95bffe2643c901dd625f0bab32e639 ] The original code set use_dma to false when dma_alloc_coherent() for bounce buffers failed, but DMA channels acquired earlier via atmel_spi_configure_dma() were never freed. When devm_request_irq() or clk_prepare_enable() failed later in probe, the driver also did not release DMA channels or bounce buffers already allocated. The out_free_dma error path released DMA channels but did not free the bounce buffers. Fix by moving bounce buffer allocation into atmel_spi_configure_dma() and registering the devres cleanup for DMA channels and bounce buffers. Fixes: a9889ed62d06 ("spi: atmel: Implements transfers with bounce buffer") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260522-atmel-v3-1-23f8c6e6aa43@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 134e0bb5a0c2a0541c050462d6f8c0ef10d4ea3e Author: Zhang Yi Date: Fri Apr 24 18:42:01 2026 +0800 ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data writeback [ Upstream commit d99748ef1695ce17eaf51c64b7a06952fa7cddab ] In EXT4_GOING_FLAGS_LOGFLUSH mode, the EXT4_FLAGS_SHUTDOWN flag was set before calling ext4_force_commit(). This caused ordered-mode data writeback (triggered by journal commit) to fail with -EIO, since ext4_do_writepages() checks for the shutdown flag. The journal would then be aborted prematurely before the commit could succeed. Fix this by calling ext4_force_commit() first, then setting the shutdown flag, so that pending data can be written back correctly. Note that moving ext4_force_commit() before setting the shutdown flag creates a small window in which new writes may occur and generate new journal transactions. When the journal is subsequently aborted, the new transactions will not be able to write to disk. This is intentional because LOGFLUSH's semantics are to flush pre-existing journal entries before shutdown, not to guarantee atomicity for writes that race with the ioctl. Fixes: 783d94854499 ("ext4: add EXT4_IOC_GOINGDOWN ioctl") Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260424104201.1930823-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit f7fca3db635022429382cf26e5b08b33558e375d Author: Pasha Tatashin Date: Wed May 27 20:27:36 2026 +0000 liveupdate: fix u-a-f in luo_file_unpreserve_files() and luo_file_finish() [ Upstream commit 291dcd37c8c8f8f8e1bccc92228f44bf371762a8 ] In luo_file_unpreserve_files() and luo_file_finish(), reorder module_put() and xa_erase() to ensure the file handler module remains pinned while its operations are being accessed. Specifically, luo_get_id() dereferences fh->ops->get_id, so the module reference must be held until after xa_erase() (which calls luo_get_id) completes. For luo_file_finish(), this requires moving the module_put() call out of the luo_file_finish_one() helper and into the main loop of luo_file_finish() itself. Fixes: 00d0b372374f ("liveupdate: prevent double management of files") Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Pratyush Yadav (Google) Signed-off-by: Pasha Tatashin Link: https://patch.msgid.link/20260527202737.1345192-5-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit bcb49f7d0a283f0c38ae951be623127856991313 Author: Pasha Tatashin Date: Wed May 27 20:27:35 2026 +0000 liveupdate: block session mutations during reboot [ Upstream commit bb1328be35bf43c88288c5c31ceb45181b574c0c ] During the reboot() syscall, user processes may still be running concurrently and attempting to mutate sessions (e.g., creating, retrieving, or releasing sessions). To prevent this, introduce luo_session_serialize_rwsem to synchronize mutations with the serialization process. All session mutation operations (create, retrieve, release, ioctl) take the read lock. The serialization process (luo_session_serialize) takes the write lock and holds it indefinitely on success. This effectively freezes the LUO session subsystem during the transition to the new kernel. If serialization fails, the lock is released to allow recovery. Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") Reported-by: Oskar Gerlicz Kowalczuk Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Pasha Tatashin Reviewed-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260527202737.1345192-4-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit d944170607b872a1f93713c555ad3f0efde3a9b8 Author: Pasha Tatashin Date: Wed May 27 20:27:34 2026 +0000 liveupdate: fix TOCTOU race in luo_session_retrieve() [ Upstream commit d3ae9e7fddb4036f50003d7fa1ef52801fdb961b ] Extend the scope of the rwsem_read lock in luo_session_retrieve() to overlap with the acquisition of the session mutex. This prevents a concurrent thread from releasing and freeing the session between the lookup and the mutex lock. Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Pratyush Yadav (Google) Signed-off-by: Pasha Tatashin Link: https://patch.msgid.link/20260527202737.1345192-3-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 2ad182a15bbc3a84ee3595cbece0e4c85de7818d Author: Pasha Tatashin Date: Wed May 27 20:27:33 2026 +0000 liveupdate: skip serialization for context-preserving kexec [ Upstream commit 5eff62b051fbdb686e885c1468301d964f2e3d66 ] A preserve_context kexec returns to the current kernel, which is unrelated to live update where the state is passed to the next kernel. Skip liveupdate_reboot() in this case to avoid serialization and prevent sessions from being left in a frozen state upon return. Fixes: db8bed8082dc ("kexec: call liveupdate_reboot() before kexec") Reported-by: Oskar Gerlicz Kowalczuk Reviewed-by: Pratyush Yadav (Google) Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Pasha Tatashin Link: https://patch.msgid.link/20260527202737.1345192-2-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 61d0ebb5a0457fcac19c95519909db6207034cfd Author: Daniel Borkmann Date: Fri May 29 18:28:29 2026 +0200 libbpf: Skip endianness swap when loader generation failed [ Upstream commit 41300d032a1b1d91a3ed996ad21905463e344beb ] bpf_gen__prog_load() byte-swaps the program insns and the {func,line}_info and CO-RE relo blobs in place for cross-endian targets. The blob offsets come from add_data(), which returns 0 on failure: realloc_data_buf() either frees and NULLs gen->data_start (realloc OOM) or returns early on an already-latched gen->error, leaving a stale, possibly too-small buffer. Neither bswap site checked for this. With gen->swapped_endian set and a failed generation, "gen->data_start + off" becomes NULL + 0. Guard the same way via !gen->error so they are skipped once generation has failed. Fixes: 8ca3323dce43 ("libbpf: Support creating light skeleton of either endianness") Reported-by: sashiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529162829.315921-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a8f448943e1a9c8e1f2fb4aa2302309cf5eeefdd Author: Daniel Borkmann Date: Fri May 29 11:41:17 2026 +0200 libbpf: Skip hash computation when loader generation failed [ Upstream commit 3c5e2f1a85844abbb65df4694f5ebad0a13e219c ] bpf_gen__finish() calls compute_sha_update_offsets() gated only on the gen_hash option, without first consulting gen->error. On a failed generation this is buggy: a failed realloc_data_buf() sets gen->data_start to NULL (leaving gen->data_cur dangling), so compute_sha_update_offsets() runs libbpf_sha256() over a NULL buffer with a bogus length; a failed realloc_insn_buf() likewise sets gen->insn_start to NULL and the hash immediates get patched through that NULL base. The computed program is discarded in either case, since the following "if (!gen->error)" block does not publish opts->insns once an error is set. Thus, skip the hash pass when generation has already failed. Fixes: ea923080c145 ("libbpf: Embed and verify the metadata hash in the loader") Reported-by: sashiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529094119.307264-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 725ada0273a0f48a67fd59cc518d7f8055fe3d5c Author: David Matlack Date: Thu Apr 23 17:40:29 2026 +0000 liveupdate: Reference count incoming FLB data [ Upstream commit d8e47bd066d7e626f9f45d416182d585b7e18b9b ] Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs. Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state") Signed-off-by: David Matlack Reviewed-by: Samiullah Khawaja Reviewed-by: Pasha Tatashin Link: https://lore.kernel.org/r/20260423174032.3140399-3-dmatlack@google.com Signed-off-by: Pasha Tatashin Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 271616cd0fe7ad591eaa253c8e8aade3af03d237 Author: David Matlack Date: Thu Apr 23 17:40:28 2026 +0000 liveupdate: Use refcount_t for FLB reference counts [ Upstream commit d2850ff2f8c5acda4c1097aa53c006a75b091f2c ] Use refcount_t instead of a raw integer to keep track of references on incoming and outgoing FLBs. Using refcount_t provides protection from overflow, underflow, and other issues. Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state") Signed-off-by: David Matlack Reviewed-by: Samiullah Khawaja Reviewed-by: Pasha Tatashin Link: https://lore.kernel.org/r/20260423174032.3140399-2-dmatlack@google.com Signed-off-by: Pasha Tatashin Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 7d177b1f7974b133e1a014e018e6fa05ba102c7b Author: Yuyang Huang Date: Sun May 31 15:56:00 2026 +0800 selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries [ Upstream commit 5add3a4ad1a3bc15404e8bd338813ed0a636f5c9 ] Add a new selftest to verify that the BPF syscall (specifically BPF_PROG_QUERY) correctly handles different user-declared attribute sizes. Specifically, verify that: - For cgroup queries, a query with a size that covers 'prog_cnt' but is smaller than 'revision' (OLD_QUERY_SIZE) succeeds, but does not write to 'revision' (verifying backward compatibility). - A query with full size (FULL_QUERY_SIZE) succeeds and writes both 'prog_cnt' and 'revision'. Fixes: 120933984460 ("bpf: Implement mprog API on top of existing cgroup progs") Cc: Maciej Żenczykowski Cc: Lorenzo Colitti Signed-off-by: Yuyang Huang Link: https://lore.kernel.org/r/20260531075600.4058207-3-yuyanghuang@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d3d630e8a7f3421bc2d204b87bdff35b4432a8e3 Author: Yuyang Huang Date: Sun May 31 15:55:59 2026 +0800 bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat [ Upstream commit 21c4b99b27f3f85b89256e81b3e997dec0a460d0 ] BPF_PROG_QUERY writes back the 'query.revision' field unconditionally to userspace. If userspace passes a smaller 'bpf_attr' structure (e.g. 40 bytes, which was the layout before the addition of 'query.revision'), the kernel performs an out-of-bounds write. Fix this by propagating the user-provided attribute size 'uattr_size' down to the cgroup query handlers, and conditionally skipping writing the revision field to userspace when the provided buffer size is insufficient. query.revision in bpf_mprog_query is structurally identical to the cgroup case: a late tail field, written unconditionally. But the backward-compat hazard is not the same. The min-historical-size test is per command, and bpf_mprog_query only serves attach types that were born with revision in the struct: - tcx_prog_query -> BPF_TCX_INGRESS/EGRESS - netkit_prog_query -> BPF_NETKIT_PRIMARY/PEER tcx, netkit, the revision field, and bpf_mprog_query itself all landed in the same v6.6 merge window (053c8e1f235d added the mprog query API + revision; tcx in e420bed02507, netkit in 35dfaad7188c). There has never been a tcx/netkit BPF_PROG_QUERY userspace that doesn't know about revision. So for these commands the minimum legitimate struct already covers offset 56-64 — no old binary can be broken here. Contrast with cgroup: BPF_PROG_QUERY on cgroup attach types shipped in 2017; revision write-back was bolted on years later (120933984460). That path has a real population of pre-revision callers. Fixes: 120933984460 ("bpf: Implement mprog API on top of existing cgroup progs") Cc: Maciej Żenczykowski Cc: Lorenzo Colitti Signed-off-by: Yuyang Huang Link: https://lore.kernel.org/r/20260531075600.4058207-2-yuyanghuang@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 731485617bf862f1289c3f40ed1f800d0475826f Author: Abd-Alrhman Masalkhi Date: Sat May 30 15:14:11 2026 +0000 raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path [ Upstream commit 909d9dc3b5730c8ed7b764c68bc788342df2a07b ] In raid1_write_request(), each per-mirror loop iteration begins by incrementing rdev->nr_pending. If a REQ_ATOMIC write encounters a badblock within the requested range, the code jumps to err_handle without dropping the reference taken for the current mirror. err_handle's cleanup loop will only decrements for k < i and r1_bio->bios[k] is non-NULL. The current slot is therefore skipped, leaving its nr_pending reference leaked permanently. The reference prevents the rdev from ever being removed, since raid1_remove_conf() refuses to remove an rdev with nr_pending > 0. Fix this by calling rdev_dec_pending() before jumping to err_handle. Fixes: f2a38abf5f1c ("md/raid1: Atomic write support") Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260530151411.4119-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bb8d7ea74206b419aa05d7773a15a923b668c9f0 Author: Abd-Alrhman Masalkhi Date: Fri May 1 13:46:51 2026 +0200 md/raid1,raid10: fix bio accounting for split md cloned bios [ Upstream commit ba976e3501111d11c550848b3b7341a73035f582 ] Use md_cloned_bio() to control bio accounting instead of relying on r1bio_existed in raid1 or the io_accounting flag in raid10. The previous logic does not reliably reflect whether a bio is an md cloned bio. When a failed bio is split and resubmitted via bio_submit_split_bioset() on the error path, this can lead to either double accounting for md cloned bios, or missing accounting for bios returned from bio_submit_split_bioset() Fix this by using md_cloned_bio() to detect md cloned bios and skip accounting accordingly. Fixes: bb2a9acefaf9 ("md/raid1: switch to use md_account_bio() for io accounting") Fixes: 820455238366 ("md/raid10: switch to use md_account_bio() for io accounting") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Xiao Ni Link: https://patch.msgid.link/20260501114652.590037-4-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 20fb582c92fd64e5c8bd83c6176264b2794603b7 Author: Abd-Alrhman Masalkhi Date: Fri May 1 13:46:50 2026 +0200 md/raid1,raid10: fix error-path detection with md_cloned_bio() [ Upstream commit 811545e0926d02a6a0b1a1258bb5544777c164d4 ] Detect the error path using md_cloned_bio() instead of relying on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be NULL or -1 after splitting and resubmitting a failed bio. As a result, the error path may not be recognized and memory allocations can incorrectly use GFP_NOIO instead of (GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under memory pressure. Fixes: 689389a06ce7 ("md/raid1: simplify handle_read_error().") Fixes: 545250f24809 ("md/raid10: simplify handle_read_error()") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Xiao Ni Link: https://patch.msgid.link/20260501114652.590037-3-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 38777f014c37972868f1733a651c85288bb8a757 Author: Abd-Alrhman Masalkhi Date: Fri May 1 13:46:49 2026 +0200 md/raid1,raid10: fix deadlock in read error recovery path [ Upstream commit 7b15c24f805339a585cfe7d72f446b7e88b9bcc0 ] raid1d and raid10d may resubmit a split md cloned bio while handling a read error. In this case, resubmitting the bio can lead to a deadlock if the array is suspended before md_handle_request() acquires an active_io reference via percpu_ref_tryget_live(). Since the cloned bio already holds an active_io reference, trying to acquire another reference via percpu_ref_tryget_live() can lead to a deadlock while the array is suspended. Fix this by using percpu_ref_get() for md cloned bios. Fixes: bb2a9acefaf9 ("md/raid1: switch to use md_account_bio() for io accounting") Fixes: 820455238366 ("md/raid10: switch to use md_account_bio() for io accounting") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Xiao Ni Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260501114652.590037-2-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit eb04e3e9c14ed15914f5fd2eae8b6435f54f095f Author: Chen Cheng Date: Fri May 15 17:30:19 2026 +0800 md/raid10: reset read_slot when reusing r10bio for discard [ Upstream commit 6b8a26af065ddc93de2aa5c9f0df98dce9723442 ] put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly. Fixes: d30588b2731f ("md/raid10: improve raid10 discard request") Signed-off-by: Chen Cheng Reviewed-by: Xiao Ni Link: https://patch.msgid.link/20260515093019.3436882-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 00a6d9771de05b03f7efe82033a3dded4a16caaf Author: Marek Vasut Date: Sun May 17 18:31:25 2026 +0200 arm64: dts: renesas: ironhide: Describe all reserved memory [ Upstream commit 5250b3b1ad99d216b31c98b2b321f1dee362a1b5 ] Fully describe all available DRAM in the DT, and describe regions which are not accessible because they are used by firmware in reserved-memory nodes. Replace the first memory bank memory@60600000 with memory@40000000 and a 518 MiB long reserved-memory no-map subnode. This memory region is used by other cores in the system. Reserve 32 kiB of memory at 0x8c100000 for parameters shared by IPL, SCP, TFA BL31 and TEE. Reserve 512 kiB of memory at 0x8c200000 for TFA BL31. The upcoming upstream TFA 2.15 BL31 uses memory from 0x8c200000..0x8c242fff; rounding up to 512 kiB is slight future-proofing. Reserve 32 MiB of memory at 0x8c400000 for OPTEE-OS, which is the entire OPTEE-OS TZ protected DRAM area. Neither TFA BL31 nor OPTEE-OS modify the DT passed to Linux in any way with any new reserved-memory {} nodes to reserve memory areas used by the TFA BL31 or OPTEE-OS to prevent the next stage from using those areas, which lets Linux use all of the available DRAM as it is described in the DT that was passed in by U-Boot, including the areas that are newly utilized by TFA BL31 or OPTEE-OS. In case of high DRAM utilization, unless the memory used by TFA BL31 or OPTEE-OS is properly reserved, Linux may use and corrupt the memory used by TFA BL31 or OPTEE-OS, which would lead to the system becoming unresponsive. Fixes: ad142a4ef710 ("arm64: dts: renesas: r8a78000: Add initial Ironhide board support") Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260517163212.18016-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 4932ed4d1bba38e51962073dbbe124789ddd58e8 Author: Marek Vasut Date: Thu May 14 14:53:06 2026 +0200 arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor description [ Upstream commit 54613573ff1495b928e2841b257c081a58566901 ] The Renesas R-Car X5H (R8A78000) SoC contains Arm CoreLink GIC-720AE Generic Interrupt Controller with Multi View capability. Firmware has access to configuration View 0, Linux kernel has access to View 1. The Arm CoreLink GIC-720AE Generic Interrupt Controller Technical Reference Manual, currently latest r2p1 [1], chapter "5. Programmers model for GIC-720AE", subchapter "5.4 Redistributor registers for control and physical LPIs summary", part "5.4.3 GICR_TYPER, Redistributor Type Register", "Table 5-50: GICR_TYPER bit descriptions" on page 200, clarifies register "GICR_TYPER" bit 4 "Last" behavior in Multi View setup as follows: Last Last Redistributor: 0 ... This Redistributor is not the last Redistributor on the chip. 1 ... This Redistributor is the last Redistributor on the chip. When GICD_CFGID.VIEW == 1, for views 1, 2, or 3 this bit always returns 1. On this SoC, GICD_CFGID.VIEW is 1 and the Linux kernel has access to View 1, therefore Linux kernel GICv3 driver will interpret register "GICR_TYPER" bit 4 "Last" = 1 in the first Redistributor in continuous Redistributor page as that first Redistributor being the one and only Redistributor and will stop processing the continuous Redistributor page further. This will prevent the other Redistributors from being recognized by the system and used for other PEs. Because the hardware indicates that the continuous Redistributor page is not continuous for View 1, 2, or 3, describe every Redistributor separately in the DT. This makes all Redistributors for all cores accessible in Linux. [1] https://documentation-service.arm.com/static/69ef3c1cd35efd294e335c43 Arm® CoreLink™ GIC-720AE Generic Interrupt Controller Revision: r2p1 / Issue 12 / 102666_0201_12_en Fixes: 63500d12cf76 ("arm64: dts: renesas: Add R8A78000 SoC support") Acked-by: Marc Zyngier Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260514125328.20954-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 62797f0d044ce0573ebdddcf77d2fadffdf3e177 Author: Danilo Krummrich Date: Tue May 5 15:37:24 2026 +0200 rpmsg: use generic driver_override infrastructure [ Upstream commit 55ced13c42921714e90f8fae94b6ed803330dc6a ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: e95060478244 ("rpmsg: Introduce a driver override mechanism") Reviewed-by: Mathieu Poirier Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260505133935.3772495-5-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 2fb010ea7ca98cd09a6d365260b769f627e73a76 Author: Danilo Krummrich Date: Tue May 5 15:37:23 2026 +0200 Drivers: hv: vmbus: use generic driver_override infrastructure [ Upstream commit 331d8900121a1d74ecd45cd2db742ddcb5a0a565 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Tested-by: Michael Kelley Reviewed-by: Michael Kelley Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: d765edbb301c ("vmbus: add driver_override support") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260505133935.3772495-4-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 3666f28016719f1476373b9b1c689d835e95718d Author: Danilo Krummrich Date: Tue May 5 15:37:22 2026 +0200 cdx: use generic driver_override infrastructure [ Upstream commit d541aa1897f67f4f14c805785bff894bcc61dca1 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 2959ab247061 ("cdx: add the cdx bus driver") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260505133935.3772495-3-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 3dcce74e455d1489fed4272cfc65271ff8dc9daa Author: Danilo Krummrich Date: Tue May 5 15:37:21 2026 +0200 amba: use generic driver_override infrastructure [ Upstream commit 1947229f5f2a8d4ecf8c971aca68a1242bb7b37c ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 3cf385713460 ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260505133935.3772495-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 4d94725aef73e83102eac726bc92ec4498042733 Author: Renjiang Han Date: Tue Mar 31 10:07:09 2026 +0530 media: qcom: venus: relax encoder frame/blur step size on v6 [ Upstream commit c53e0550288b2e08b984b24035c471941b7820c7 ] Encoder HFI capabilities on v6 enforce a 16-pixel step for frame and blur dimensions, which does not reflect actual hardware requirements and can reject valid userspace configurations. Relax the step size to 1 while leaving min/max limits unchanged. Fixes: 869d77e706290 ("media: venus: hfi_plat_v6: Populate capabilities for v6") Signed-off-by: Renjiang Han Reviewed-by: Dikshita Agarwal Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 309f922634ec382a8beb47873cb22985b0b74825 Author: Renjiang Han Date: Tue Mar 31 10:07:08 2026 +0530 media: qcom: venus: relax encoder frame/blur dimension steps on v4 [ Upstream commit 35428ae3a6a40912f1f7b47bb6c65f1a63d0b8f8 ] Encoder HFI capabilities on v4 advertise a 16-pixel step for frame and blur dimensions. This is overly restrictive and can cause userspace caps negotiation to fail even for valid resolutions. Relax the advertised step size to 1 and keep alignment enforcement in buffer layout and size calculations. Fixes: 8b88cabef404e ("media: venus: hfi_plat_v4: Populate codecs and capabilities for v4") Signed-off-by: Renjiang Han Reviewed-by: Dikshita Agarwal Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit f035a50db2515d4f33518e35eac6db5111008866 Author: Renjiang Han Date: Tue Mar 31 10:07:07 2026 +0530 media: qcom: venus: drop extra padding in NV12 raw size calculation [ Upstream commit e1c9adabb268cc5d56723b7df1da49e59070f309 ] get_framesize_raw_nv12() currently adds SZ_4K to the UV plane size and an additional SZ_8K to the total buffer size. This inflates the calculated sizeimage and leads userspace to over-allocate buffers without a clear requirement. Remove the extra SZ_4K/SZ_8K padding and compute the NV12 size as the sum of Y and UV planes, keeping the final ALIGN(size, SZ_4K) intact. Fixes: e1cb72de702ad ("media: venus: helpers: move frame size calculations on common place") Signed-off-by: Renjiang Han Reviewed-by: Dikshita Agarwal Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit c399eccc9729d7c26f5206a8df3000dd85ced79b Author: Dmitry Baryshkov Date: Tue Apr 7 01:15:52 2026 +0300 Revert "media: venus: hfi_platform: Correct supported codecs for sc7280" [ Upstream commit 3eb9ba0da0ab73e135f93ffccf07381ba11f100e ] This reverts commit c0ab2901fc68 ("media: venus: hfi_platform: Correct supported codecs for sc7280"). The codecs might be deprecated, but they still work (somewhat) perfectly and don't cause any issues with the rest of the system. Reenable VP8 codecs by reverting the offending commit. Tested with fluster: |Test|FFmpeg-VP8-v4l2m2m|GStreamer-VP8-V4L2| |TOTAL|50/61|50/61| |TOTAL TIME|12.171s|11.824s| Fixes: c0ab2901fc68 ("media: venus: hfi_platform: Correct supported codecs for sc7280") Signed-off-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit f6db9ffab324344197b28dadf3f3c326d7edd4ce Author: Yixun Lan Date: Mon May 18 20:58:16 2026 +0000 dts: riscv: spacemit: k3: Fix I/O power settings [ Upstream commit 3ea695eb111fc5a7ffddd21d5c3fee6d82560413 ] SpacemiT K3 SoC support dual-voltage I/O power domain, while initially configure to 3.3v, and need to access register from APBC space to switch to 1.8v domain. Fix the GMAC0's I/O pins 1.8v switch failure that will result a broken ethernet driver. Fixes: d8944577496b ("riscv: dts: spacemit: k3: add pinctrl support") Reported-by: Han Gao Link: https://patch.msgid.link/20260518-07-dts-pinctrl-io-power-v1-1-abe19c14a726@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit a211b7904aed365e4e4f08a48ec6e6dd1ea7b16b Author: Tristan Madani Date: Mon May 18 21:50:40 2026 +0000 RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path [ Upstream commit d6ab440240a04b8737ee4c7bb21af9182e451733 ] For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data(). Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260518215040.1598586-3-tristan@talencesecurity.com Signed-off-by: Tristan Madani Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b9800d7953d119bcc068c74587d48e4ba0313629 Author: Tristan Madani Date: Mon May 18 21:50:39 2026 +0000 RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe [ Upstream commit 22b8fbded65b8c441b634a185f8da67657df6c50 ] get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260518215040.1598586-2-tristan@talencesecurity.com Signed-off-by: Tristan Madani Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 168670d9c56ec80c9ac836fcf583d9dfc1dfe50a Author: Jiri Pirko Date: Fri May 29 15:43:10 2026 +0200 RDMA/umem: Add ib_umem_is_contiguous() stub for !CONFIG_INFINIBAND_USER_MEM [ Upstream commit 2cc10972f5f4f123e5a7658824db4f7b5abfc410 ] ib_umem_is_contiguous() is defined under #ifdef CONFIG_INFINIBAND_USER_MEM, but the #else branch lacks a stub. Add the missing inline to fix potential broken build. Fixes: c897c2c8b8e8 ("RDMA/core: Add umem "is_contiguous" and "start_dma_addr" helpers") Link: https://patch.msgid.link/r/20260529134312.2836341-15-jiri@resnulli.us Signed-off-by: Jiri Pirko Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 31a19a68c83b39ed14c6e401387886aae68ddee0 Author: Jinseok Kim Date: Wed May 27 19:39:26 2026 +0900 arm: dts: bcm2711: Fix typo in gpio-line-names [ Upstream commit 245552af869d35ae27cac2121696dd630f15b3bf ] Replace "RGMIO_MDC" with "RGMII_MDC" in gpio-line-names. Signed-off-by: Jinseok Kim Link: https://lore.kernel.org/r/20260527103930.2973-1-always.starving0@gmail.com Fixes: cd87c180b301 ("ARM: dts: bcm2711-rpi-4-b: Add SoC GPIO labels") Fixes: ea93ada05c9e ("ARM: dts: Add Raspberry Pi Compute Module 4 IO Board") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 558626dc9d73fcd0810b7ae565aca83a00524726 Author: Marek Vasut Date: Sat Apr 11 15:02:35 2026 +0200 arm64: dts: st: Fix SAI addresses on stm32mp251 [ Upstream commit fba4a31a7f3b6b29b01c83180f83e7ed4c398738 ] The second field of SAI register addresses should be within 0x3f0 bytes from the start of the SAI register addresses, the second field describes the ID registers which are at that addrses. Currently, the second field does not match RM, fix it. Fixes: bf26d75a95f1 ("arm64: dts: st: add sai support on stm32mp251") Signed-off-by: Marek Vasut Reviewed-by: Olivier Moysan Link: https://lore.kernel.org/r/20260411130300.19603-1-marex@nabladev.com Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit c6e1cab54a06cd6481adf21630ddd97b43f69edd Author: zhoumin Date: Thu Mar 26 17:14:03 2026 +0800 EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in skx_get_dimm_info [ Upstream commit c63ed6e1f5fe648a4a099b6717f679999be482ef ] When the skx_get_dimm_attr() helper returns -EINVAL, skx_get_dimm_info() does not validate these return values before using them in a shift operation: size = ((1ull << (rows + cols + ranks)) * banks) >> (20 - 3); If all three values are -22, the shift exponent becomes -66, triggering a UBSAN shift-out-of-bounds error: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c shift exponent -66 is negative Fixes: 88a242c98740 ("EDAC, skx_common: Separate common code out from skx_edac") Signed-off-by: zhoumin Signed-off-by: Tony Luck Link: https://patch.msgid.link/tencent_2A0CC835A18366643CBD2865B169948AB409@qq.com Signed-off-by: Sasha Levin commit 63bbfadcbaf778eded12ec249daf77d303d9cd80 Author: Qiuxu Zhuo Date: Fri Apr 3 13:40:28 2026 +0800 EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs [ Upstream commit 114bfa24eacb688488caa2e459358a1b9b89b16d ] Panther Lake-H SoC memory controller registers for memory topology have been updated, but the current igen6_edac driver still uses old generation ones to incorrectly parse memory topology. Fix the issue by adding memory topology parsing function pointers to the 'struct res_config' and creating a new configuration structure for Panther Lake-H SoCs to enable igen6_edac to parse memory correctly. Fixes: 0be9f1af3902 ("EDAC/igen6: Add Intel Panther Lake-H SoCs support") Fixes: 4c36e6106997 ("EDAC/igen6: Add more Intel Panther Lake-H SoCs support") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260403054029.3950383-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit a341302c5126ef96bb45286224d67ef60a24281e Author: Qiuxu Zhuo Date: Fri Apr 3 13:40:27 2026 +0800 EDAC/igen6: Fix call trace due to missing release() [ Upstream commit ab1f9d466c7d83ab0d2a529e07984e53b5960dcd ] When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260403054029.3950383-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit cbaa5e2d04aad0aa2a4c83d105c3b419ede2c2a4 Author: Akhil P Oommen Date: Fri May 22 15:41:57 2026 +0530 drm/msm/a8xx: Fix RSCC offset [ Upstream commit 586a34dafc08c4fa68d1b4673de24cd84d09df05 ] In A8xx, the RSCC block is part of GPU's register space. Update the virtual base address of rscc to point to the correct address. Fixes: 50e8a557d8d3 ("drm/msm/a8xx: Add support for A8x GMU") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/727117/ Message-ID: <20260522-glymur-gpu-dt-v5-1-562c406b210c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 93657584450d83c5eb49d81ae6863892b0e1d386 Author: Akhil P Oommen Date: Mon Apr 27 12:08:59 2026 +0530 drm/msm/a8xx: Make a8xx_recover IFPC safe [ Upstream commit e7c45d9838b7487c1846a0202c649336b2f5bf87 ] Similar to a6xx_recover(), check the GX power domain status before accessing mmio in GX domain a8xx_recover(). Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Akhil P Oommen Reviewed-by: Konrad Dybcio Signed-off-by: Taniya Das Patchwork: https://patchwork.freedesktop.org/patch/720977/ Message-ID: <20260427-gfx-clk-fixes-v2-5-797e54b3d464@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit f0115af6746eaee0232cefb6f38048a14c06cffb Author: Arnd Bergmann Date: Fri May 29 15:43:31 2026 +0200 firmware: samsung: acpm: remove compile-testing stubs [ Upstream commit 7b661285aa7507eab79efff0a418445157db4141 ] Sashiko reported an inconsistent use of NULL vs ERR_PTR() returns in the stub helpers in xynos-acpm-protocol.h. Since this only happens on dead code for COMPILE_TEST=y, this is not really a bug though. Having stub functions that return NULL is a common way to define optional interfaces, where callers still work when the feature is disabled, though this clearly does not work for acpm because some callers have a NULL pointer dereference when compile testing. Since CONFIG_EXYNOS_ACPM_PROTOCOL already supports compile-testing itself, and all (both) drivers using it clearly require the support, so this just simplifies the option space without losing any build coverage. Remove the stub functions entirely and adjust the one Kconfig dependency to require EXYNOS_ACPM_PROTOCOL unconditionally. Fixes: 6837c006d4e7 ("firmware: exynos-acpm: add empty method to allow compile test") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org Link: https://lore.kernel.org/all/a7994860-24a3-4f87-84bf-109ed653dda4@linaro.org/ Reviewed-by: Tudor Ambarus Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260529134454.2147446-1-arnd@kernel.org [krzk: Rebase on difference in devm_acpm_get_by_node()] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 75c70913d30c3b3c395a4efa0d8c0e9c90553fa7 Author: Tudor Ambarus Date: Fri May 15 09:32:30 2026 +0000 firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper [ Upstream commit fc13a4b9b9c8cb0b8e5ba54b21712d00f810496c ] Introduce devm_acpm_get_by_phandle() to standardize how consumer drivers acquire a handle to the ACPM IPC interface. Enforce the use of the "samsung,acpm-ipc" property name across the SoC and simplify the boilerplate code in client drivers. The first consumer of this helper is the Exynos ACPM Thermal Management Unit (TMU) driver. The TMU utilizes a hybrid management approach: direct register access from the Application Processor (AP) is restricted to the interrupt pending (INTPEND) registers for event identification. High-level functional tasks, such as sensor initialization, threshold programming, and temperature reads, are delegated to the ACPM firmware via this IPC interface. Signed-off-by: Tudor Ambarus Reviewed-by: Peter Griffin Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-6-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski Stable-dep-of: 7b661285aa75 ("firmware: samsung: acpm: remove compile-testing stubs") Signed-off-by: Sasha Levin commit e80925b3fd9c2e68f61aeee0c633805e3f0bb400 Author: Jessica Zhang Date: Sun May 24 13:33:30 2026 +0300 drm/msm/dp: Fix the ISR_* enum values [ Upstream commit 3fbfdc3b1d48cc115a86953e5df0c76cd2efc42b ] The ISR_HPD_* enum should represent values that can be read from the REG_DP_DP_HPD_INT_STATUS register. Swap ISR_HPD_IO_GLITCH_COUNT and ISR_HPD_REPLUG_COUNT to map them correctly to register values. While we are at it, correct the spelling for ISR_HPD_REPLUG_COUNT. Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Signed-off-by: Jessica Zhang Reviewed-by: Konrad Dybcio Tested-by: Val Packett # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/727602/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-2-cf3ab488dd7b@oss.qualcomm.com Signed-off-by: Sasha Levin commit 20dbc65b23c26486e995c8b703b51f579a162b5e Author: Jessica Zhang Date: Sun May 24 13:33:29 2026 +0300 drm/msm/dp: fix HPD state status bit shift value [ Upstream commit 2e6c2e81d81251623c458a60e2a57447dcbc988e ] The HPD state status is the 3 most significant bits, not 4 bits of the HPD_INT_STATUS register. Fix the bit shift macro so that the correct bits are returned in msm_dp_aux_is_link_connected(). Fixes: 19e52bcb27c2 ("drm/msm/dp: return correct connection status after suspend") Signed-off-by: Jessica Zhang Reviewed-by: Konrad Dybcio Tested-by: Val Packett # x1e80100-dell-latitude-7455 Tested-by: Yongxing Mou # Hamoa IOT EVK, QCS8300 Ride Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/727611/ Link: https://lore.kernel.org/r/20260524-hpd-refactor-v6-1-cf3ab488dd7b@oss.qualcomm.com Signed-off-by: Sasha Levin commit 32af7d581353a6c35d6664468786cd159772af3d Author: Andrea Righi Date: Tue May 26 12:05:02 2026 +0200 sched/deadline: Reject debugfs dl_server writes for offline CPUs [ Upstream commit 4043f549841619a01999bf5d4e0b7931ef87f6cc ] Writing runtime or period via the per-CPU dl_server debugfs files (/sys/kernel/debug/sched/{fair,ext}_server/cpu*/{runtime,period}) on an offline CPU can trigger two distinct kernel issues: 1) Divide-by-zero in dl_server_apply_params(): Oops: divide error: 0000 [#1] SMP NOPTI RIP: 0010:dl_server_apply_params+0x239/0x3a0 Call Trace: sched_server_write_common.isra.0+0x21a/0x3c0 full_proxy_write+0x78/0xd0 vfs_write+0xe7/0x6e0 Both __dl_sub() and __dl_add() divide by cpus internally, which can be 0 once the CPU has been removed from any active root-domain span (this has been latent since the debugfs interface was introduced). 2) WARN_ON_ONCE in dl_server_start(): WARNING: kernel/sched/deadline.c:1805 at dl_server_start+0x232/0x270 Commit ee6e44dfe6e5 ("sched/deadline: Stop dl_server before CPU goes offline") added this check to catch enqueueing the server on an offline rq. There's no meaningful semantics for re-configuring the per-CPU dl_server bandwidth while the CPU is offline, so simply reject the write with -EBUSY so userspace gets a clear error. Closes: https://lore.kernel.org/all/20260526092228.3B6891F00A3A@smtp.kernel.org/ Fixes: d741f297bcea ("sched/fair: Fair server interface") Reported-by: Sashiko Signed-off-by: Andrea Righi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Tested-by: abaci-kreproducer Link: https://patch.msgid.link/20260526100502.575774-1-arighi@nvidia.com Signed-off-by: Sasha Levin commit 6945ad6db8d939c668f50e8ba2af24e50bcc4fe7 Author: Alexey Kardashevskiy Date: Thu May 21 17:43:01 2026 +1000 crypto: ccp/tsm - Enable the root port after the endpoint [ Upstream commit 50e506201bab875545c7a9443bd7e1c71804e553 ] The PCIe r7.0, chapter "6.33.8 Other IDE Rules" mandates if selective IDE is enabled for config requersts, a stream must be enabled on the endpoint before enabling it on the rootport: === For Selective IDE, the Stream must not be used until it has been enabled in both Partner Ports. For cases where one of the Partner Ports is a Root Port and Selective IDE for Configuration Requests is enabled, the other Partner Port must be enabled prior to the Root Port. For other scenarios, the mechanisms to satisfy this requirement are implementation-specific. === Do what the spec says. Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)") Signed-off-by: Alexey Kardashevskiy Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 20360e125a8dd411b0cc2660cb70f58590740818 Author: Herbert Xu Date: Wed May 20 10:51:14 2026 +0800 crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm [ Upstream commit 690a5f9e5c972a580565ce544ed1627ccf1e84de ] Ensure the ENOMEM error value is set when the input buffer allocation fails in tegra_ccm_do_one_req. Fixes: 1e245948ca0c ("crypto: tegra - finalize crypto req on error") Reported-by: Vladislav Dronov Signed-off-by: Herbert Xu Reviewed-by: Vladislav Dronov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ec49878f2780a985b9efbd68121979c493f4afbd Author: Herbert Xu Date: Tue May 19 12:22:18 2026 +0800 crypto: tegra - Fix dma_free_coherent size error [ Upstream commit 03215b8457784540acc741e6331e355b62c6c8ab ] When freeing a coherent DMA buffer, the size must match the value that was used during the allocation. Unfortunately the size field in the tegra driver gets overwritten by this point so it no longer matches and creates a warning. Fix this by saving a copy of the size on the stack. Note that the ccm function actually mixes up the inbuf and outbuf sizes, but it doesn't matter because the two sizes are actually equal. Fixes: 1cb328da4e8f ("crypto: tegra - Do not use fixed size buffers") Reporeted-by: Patrick Talbert Signed-off-by: Herbert Xu Reviewed-by: Vladislav Dronov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 27bddeff3d10b3538e99a6dbf9b2c54bbd7ea6a1 Author: Aleksander Jan Bajkowski Date: Mon May 18 23:24:59 2026 +0200 crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq [ Upstream commit 85a61bf9145d4097c740ffcf3aa832d930a8913b ] As the potential failure of the devm_request_threaded_irq(), it should be better to check the return value and return error if fails. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4b409fb6b630cd4ecd190182fa99fcfca2675116 Author: Weili Qian Date: Mon May 18 22:29:54 2026 +0800 crypto: hisilicon/qm - disable error report before flr [ Upstream commit e71dc5602b9a29027f6aedd5990d3e8c4f638c8c ] Before function level reset, driver first disable device error report and then waits for the device reset to complete. However, when the error is recovered, the error bits will be enabled again, resulting in invalid disable. It is modified to detect that there is no error before disable error report, and then do FLR. Fixes: 7ce396fa12a9 ("crypto: hisilicon - add FLR support") Signed-off-by: Weili Qian Signed-off-by: Zongyu Wu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3c220eccfb3bf549af0aadd42fe451fc9c99ac1e Author: Tetsuo Handa Date: Mon May 18 13:23:40 2026 +0900 ocfs2: kill osb->system_file_mutex lock [ Upstream commit f5b1910e23f1233c8d4185268b2e659df2bc5dbf ] Commit 43b10a20372d ("ocfs2: avoid system inode ref confusion by adding mutex lock") tried to avoid a refcount leak caused by allowing multiple threads to call igrab(inode). But addition of osb->system_file_mutex made locking dependency complicated and is causing lockdep to warn about possibility of AB-BA deadlock. Since _ocfs2_get_system_file_inode() returns the same inode for the same input arguments, we don't need to serialize _ocfs2_get_system_file_inode(). What we need to make sure is that igrab(inode) is called for only once(). Therefore, replace osb->system_file_mutex with cmpxchg()-based locking. Link: https://lore.kernel.org/fea8d1fd-afb0-4302-a560-c202e2ef7afd@I-love.SAKURA.ne.jp Fixes: 43b10a20372d ("ocfs2: avoid system inode ref confusion by adding mutex lock") Signed-off-by: Tetsuo Handa Reviewed-by: Heming Zhao Acked-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5b33f99f3e48465bd93219495381a5aef4fa967f Author: ZhengYuan Huang Date: Tue May 12 10:41:15 2026 +0800 ocfs2: don't BUG_ON an invalid journal dinode [ Upstream commit c0438198c28b1d22c272751af5e717c11d9fa8dd ] [BUG] A fuzzed OCFS2 image can corrupt the current slot journal dinode while mount is still in progress. The mount path first reports the invalid journal block and then crashes in shutdown: kernel BUG at fs/ocfs2/journal.c:1034! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_journal_toggle_dirty+0x2d6/0x340 fs/ocfs2/journal.c:1034 Call Trace: ocfs2_journal_shutdown+0x414/0xc30 fs/ocfs2/journal.c:1116 ocfs2_mount_volume fs/ocfs2/super.c:1785 [inline] ocfs2_fill_super+0x30a9/0x3cd0 fs/ocfs2/super.c:1083 get_tree_bdev_flags+0x38b/0x640 fs/super.c:1698 get_tree_bdev+0x24/0x40 fs/super.c:1721 ocfs2_get_tree+0x21/0x30 fs/ocfs2/super.c:1184 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... [CAUSE] ocfs2_journal_toggle_dirty() used to return -EIO when journal->j_bh no longer contained a valid dinode, because the startup and shutdown paths already handled that failure. Commit 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") changed the check to a BUG_ON() under the assumption that the journal dinode had already been validated. That turns an unexpected invalid journal dinode during mount teardown into a kernel crash instead of a normal mount failure. [FIX] Replace the BUG_ON() with WARN_ON() and return -EIO. This keeps the invariant warning for debugging, but restores the original behavior of failing startup or shutdown cleanly instead of panicking the kernel. Link: https://lore.kernel.org/20260512024115.4036371-1-gality369@gmail.com Fixes: 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit dc28a14f3e4546b2b06098d24177942540581a5f Author: Dan Carpenter Date: Fri May 8 10:51:56 2026 +0300 rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc() [ Upstream commit fc15e3a30ddd950f009c76765331783b9af94a87 ] With a list_for_each() loop, if we don't find the item we are looking for in the list, then the loop exits with the iterator, which is "dbell" in this loop, pointing to invalid memory. This code uses the "found" variable to determine if we have found the doorbell we are looking for or not. However, the problem that the "found" variable needs to be set to false at the start of each iteration, otherwise after the first correct doorbell, then everything is marked as found. Reset the "found" to false at the start of the iteration and move the variable inside the loop. Link: https://lore.kernel.org/af2WHMZiqMwdYveO@stanley.mountain Fixes: 48618fb4e522 ("RapidIO: add mport driver for Tsi721 bridge") Signed-off-by: Dan Carpenter Cc: Alexandre Bounine Cc: Chul Kim Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9d27b6f190bd41739e7301472cc21903208cd59b Author: Yury Norov Date: Fri Apr 24 22:08:57 2026 -0400 uaccess: minimize INLINE_COPY_USER-related ifdefery [ Upstream commit bd99fcfc6219ebe36ae4d0bf5333b5ecc17b53df ] Now that we've got the same config selecting inline vs outline copy_to_user() and copy_from_user(), we can simplify the corresponding logic in the uaccess.h. Link: https://lore.kernel.org/20260425020857.356850-4-ynorov@nvidia.com Fixes: 1f9a8286bc0c ("uaccess: always export _copy_[from|to]_user with CONFIG_RUST") Signed-off-by: Yury Norov Tested-by: Alice Ryhl Cc: Arnd Bergmann Cc: Christophe Leroy (CS GROUP) Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Viktor Malik Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 86c1d7f3e548af9c7e7dbcf5d1bfc2bb52e5aa4e Author: Yury Norov Date: Fri Apr 24 22:08:56 2026 -0400 uaccess: unify inline vs outline copy_{from,to}_user() selection [ Upstream commit c02be2ad2b88c67c5d7c06b6aa7083b5b40e1077 ] The kernel allows arches to select between inline and outline implementations of the copy_{from,to}_user() by defining individual INLINE_COPY_FROM_USER and INLINE_COPY_TO_USER, correspondingly. However, all arches enable or disable them always together. Without the real use-case for one helper being inlined while the other outlined, having independent controls is excessive and error prone. Switch the codebase to the single unified INLINE_COPY_USER control. Link: https://lore.kernel.org/20260425020857.356850-3-ynorov@nvidia.com Signed-off-by: Yury Norov Tested-by: Alice Ryhl Cc: Arnd Bergmann Cc: Christophe Leroy (CS GROUP) Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Viktor Malik Signed-off-by: Andrew Morton Stable-dep-of: bd99fcfc6219 ("uaccess: minimize INLINE_COPY_USER-related ifdefery") Signed-off-by: Sasha Levin commit 34f692ba3f755ad6ba598e01dfd39df96482cffc Author: Yury Norov Date: Fri Apr 24 22:08:55 2026 -0400 rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user() [ Upstream commit f829d4d911cc296b32d14436a8a517e907228475 ] Patch series "uaccess: unify inline vs outline copy_{from,to}_user() selection", v2. The kernel allows arches to select between inline and outline implementations of the copy_{from,to}_user() by defining individual INLINE_COPY_FROM_USER and INLINE_COPY_TO_USER, correspondingly. However, all arches enable or disable them always together. Without the real use-case for one helper being inlined while the other outlined, having independent controls is excessive and error prone. The first patch of the series fixes rust/uaccess coppy_to_user() wrapper guarded with INLINE_COPY_FROM_USER. The 2nd patch switches codebase to the unified INLINE_COPY_USER. And the last patch cleans up ifdefery in the include/linux/uaccess.h This patch (of 3): The copy_to_user() rust helper is only needed when the main kernel inlines the function. It is controlled by INLINE_COPY_TO_USER, but the rust helper is protected with INLINE_COPY_FROM_USER. Fix that. Link: https://lore.kernel.org/20260425020857.356850-1-ynorov@nvidia.com Link: https://lore.kernel.org/20260425020857.356850-2-ynorov@nvidia.com Fixes: d99dc586ca7c7 ("uaccess: decouple INLINE_COPY_FROM_USER and CONFIG_RUST") Signed-off-by: Yury Norov Reported-by: Christophe Leroy (CS GROUP) Closes: https://lore.kernel.org/all/746c9c50-20c4-4dc9-a539-bf1310ff9414@kernel.org/ Cc: Alice Ryhl Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Viktor Malik Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fd134f19825d373fd5188500f9861729aba2f605 Author: Josh Law Date: Tue Mar 24 22:32:09 2026 +0000 lib/base64: validate before writing in decode tail path [ Upstream commit cae29a5787e38ce7ec7727a87ac7e393a85cb1ef ] Patch series "lib/base64: decode fixes", v2. Two small fixes for lib/base64.c: 1. base64_decode() writes a decoded byte to the output buffer before validating the input in the trailing-bytes path. Move the validity checks before any writes so dst is untouched on invalid input. 2. The @padding kernel-doc for base64_decode() was copy-pasted from base64_encode() and describes the wrong direction. This patch (of 2): The trailing-bytes path in base64_decode() writes a decoded byte to the output buffer before checking whether the input characters are valid. If the input is malformed, garbage is written to dst before the function returns -1. Move the validity checks before any writes so the output buffer is left untouched on invalid input. Link: https://lore.kernel.org/20260324223210.47676-1-objecting@objecting.org Link: https://lore.kernel.org/20260324223210.47676-2-objecting@objecting.org Fixes: 9c7d3cf94d33 ("lib/base64: rework encode/decode for speed and stricter validation") Signed-off-by: Josh Law Reviewed-by: Andrew Morton Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 30ea97affbcce236c57287c82dc6ef7a29c63b76 Author: Davidlohr Bueso Date: Mon Feb 23 12:15:16 2026 -0800 dax/kmem: account for partial discontiguous resource upon removal [ Upstream commit 8aa442cfce79e2d69e72fc8e0c0864ac2971149d ] When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed. Link: https://lore.kernel.org/20260223201516.1517657-1-dave@stgolabs.net Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support") Signed-off-by: Davidlohr Bueso Reviewed-by: Ben Cheatham Reviewed-by: Alison Schofield Reviewed-by: Jonathan Cameron Cc: Dan Williams Cc: Dave Jiang Cc: Vishal Verma Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 146580b2cef4a02b068a74ed54e7f097bc3637d6 Author: Danilo Krummrich Date: Tue May 26 02:04:41 2026 +0200 rust: devres: add 'static bound to Devres [ Upstream commit 016267b521b18529c977c9eca9597a1669c3d73c ] Devres::new() registers a callback with the C devres subsystem via devres_node_add(). If the Devres is leaked (e.g. via core::mem::forget(), which is safe), its Drop impl never runs, and the devres release callback will revoke the inner Revocable on device unbind, which drops T in place. If T contains non-'static references, those may be dangling by that point. Add a 'static bound to prevent storing types with borrowed data in Devres. Fixes: 76c01ded724b ("rust: add devres abstraction") Reviewed-by: Alexandre Courbot Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260526000447.350558-1-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit da5715a1cc3329442d87104560310218a5ce0b77 Author: Brian Norris Date: Tue Apr 28 13:06:58 2026 -0700 arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware [ Upstream commit f0fbedccae9e16624977cca02216ab2399f5a3ab ] Chromium/Depthcharge bootloaders may dynamically add a few device nodes to a system's DTB under a /firmware node. A typical DT looks something like the following: / { firmware { ranges; coreboot { compatible = "coreboot"; reg = <...>; ...; }; }; }; Notably, the /firmware node has an empty 'ranges', but does not have address/size-cells. Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") started requiring #address-cells for a device's parent if we want to use the reg resource in a device node. This leads to errors like the following: [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 Add appropriate #{address,size}-cells to work around the problem. Note that Google has also patched the Depthcharge bootloader source to add {address,size}-cells [1], but bootloader updates are typically delivered only via Google OS updates. Not all users install Google software updates, and even if they do, Google may not produce updated binaries for all/older devices. [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/ https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and #size-cells for firmware node") Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/ Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ac77e295b05b097984e5a8052c53389916313321 Author: Brian Norris Date: Tue Apr 28 13:06:55 2026 -0700 ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware [ Upstream commit 1fe27b10dc97c85821dfae1e4e6f9db4472287aa ] Chromium/Depthcharge bootloaders may dynamically add a few device nodes to a system's DTB under a /firmware node. A typical DT looks something like the following: / { firmware { ranges; coreboot { compatible = "coreboot"; reg = <...>; ...; }; }; }; Notably, the /firmware node has an empty 'ranges', but does not have address/size-cells. Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") started requiring #address-cells for a device's parent if we want to use the reg resource in a device node. This leads to errors like the following: [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 Add appropriate #{address,size}-cells to work around the problem. Note that Google has also patched the Depthcharge bootloader source to add {address,size}-cells [1], but bootloader updates are typically delivered only via Google OS updates. Not all users install Google software updates, and even if they do, Google may not produce updated binaries for all/older devices. [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/ https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and #size-cells for firmware node") Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/ Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b6c9331d84ca1fde11468a89567df081415b103d Author: Carlos Llamas Date: Sat May 23 16:27:21 2026 +0000 libbpf: Fix UAF in strset__add_str() [ Upstream commit b23705e6afb6ac4ae6d220dcb35975698667dd76 ] strset_add_str_mem() might reallocate the strset data buffer in order to accommodate the provided string 's'. However, if 's' points to a string already present in the buffer, it becomes dangling after the realloc. This leads to a use-after-free when attempting to memcpy() the string into the new buffer. One scenario that triggers this problematic path is when resolve_btfids attempts to patch kfunc prototypes using existing BTF parameter names: | resolve_btfids: function bpf_list_push_back_impl already exists in BTF | Segmentation fault (core dumped) Compiling resolve_btfids with fsanitize=address generates a detailed report of the UAF: | ================================================================= | ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 | ==1507892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 at pc 0x55d25155a2a8 bp 0x7ffcef879060 sp 0x7ffcef878818 | READ of size 5 at 0x7f4c4a500bd4 thread T0 | #0 0x55d25155a2a7 in memcpy (tools/bpf/resolve_btfids/resolve_btfids+0xcf2a7) | #1 0x55d2515d708e in strset__add_str tools/lib/bpf/strset.c:162:2 | #2 0x55d2515c730b in btf__add_str tools/lib/bpf/btf.c:2109:8 | #3 0x55d2515c9020 in btf__add_func_param tools/lib/bpf/btf.c:3108:14 | #4 0x55d25159f0b5 in process_kfunc_with_implicit_args tools/bpf/resolve_btfids/main.c:1196:9 | #5 0x55d25159e004 in btf2btf tools/bpf/resolve_btfids/main.c:1229:9 | #6 0x55d25159cee7 in main tools/bpf/resolve_btfids/main.c:1535:6 | #7 0x7f4c78e29f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 | #8 0x7f4c78e2a026 in __libc_start_main csu/../csu/libc-start.c:360:3 | #9 0x55d2514bb860 in _start (tools/bpf/resolve_btfids/resolve_btfids+0x30860) | | 0x7f4c4a500bd4 is located 13268 bytes inside of 2829000-byte region [0x7f4c4a4fd800,0x7f4c4a7b02c8) | freed by thread T0 here: | #0 0x55d25155b700 in realloc (tools/bpf/resolve_btfids/resolve_btfids+0xd0700) | #1 0x55d2515c426c in libbpf_reallocarray tools/lib/bpf/./libbpf_internal.h:220:9 | #2 0x55d2515c426c in libbpf_add_mem tools/lib/bpf/btf.c:224:13 | | previously allocated by thread T0 here: | #0 0x55d25155b2e3 in malloc (tools/bpf/resolve_btfids/resolve_btfids+0xd02e3) | #1 0x55d2515d6e7d in strset__new tools/lib/bpf/strset.c:58:20 While resolve_btfids could be refactored to avoid this call path, let's instead fix this issue at the source in strset__add_str() and avoid similar scenarios. Let's check if set->strs_data was reallocated and whether 's' points to an internal string within the old strset buffer. In such case, 's' is reconstructed to point to the new buffer. While already here, also fix strset__find_str() which suffers from the same problem by factoring out the common operations into a new helper function strset_str_append(). Fixes: 90d76d3ececc ("libbpf: Extract internal set-of-strings datastructure APIs") Suggested-by: Andrii Nakryiko Suggested-by: Mykyta Yatsenko Signed-off-by: Carlos Llamas Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260523162722.2718940-1-cmllamas@google.com Signed-off-by: Sasha Levin commit a1253892dd66dbee17815e7373b2e551343dbd8a Author: Siddharth Nayyar Date: Wed May 20 09:40:44 2026 +0000 bpftool: Fix typo in struct_ops map FD generation for light skeleton [ Upstream commit be4c6c7bc42952b71188894933946b410deadcfe ] When generating light skeletons for BPF programs containing struct_ops maps, bpftool incorrectly outputs a stray literal 't' instead of a tab character for the map file descriptor member in the links structure. This causes a compilation error when the generated light skeleton is used. Correct the format string by replacing 't' with '\t'. Fixes: 08ac454e258e ("libbpf: Auto-attach struct_ops BPF maps in BPF skeleton") Signed-off-by: Siddharth Nayyar Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260520-struct_ops_gen_typo_fix-v1-1-4dee3771da46@google.com Signed-off-by: Sasha Levin commit 63e5aa348fd41afac57243f69d03e4408c2bfd20 Author: Michael Bommarito Date: Fri May 22 16:13:53 2026 -0400 libbpf: Harden parse_vma_segs() path parsing [ Upstream commit fee9a38174f4c6454fb1fbaf2b9b5a1cca9070d0 ] parse_vma_segs() in tools/lib/bpf/usdt.c parses /proc//maps with two widthless scansets, "%s" into mode[16] and "%[^\n]" into line[4096]. A VMA name in maps is not limited to that local buffer; a deeply nested backing path can produce a maps record long enough to overflow the stack buffer. Bound both scansets to the declared buffer sizes ("%15s" for mode[16] and "%4095[^\n]" for line[4096]) and drain any residue past line[4094] with "%*[^\n]" before the trailing "\n". Without the drain, the residue of an over-long record would stay in the stream and break the next "%zx-%zx" parse, so the loop would exit early and silently skip later maps records. Also stop using sscanf(..., "%s") to peel the /proc//root prefix from lib_path. Parse the pid and prefix length with "%n", check for the following slash, and copy the remainder with libbpf_strlcpy(). That removes a second unbounded stack write and preserves paths containing spaces. Fixes: 74cc6311cec9 ("libbpf: Add USDT notes parsing and resolution logic") Signed-off-by: Michael Bommarito Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260522201353.1454653-1-michael.bommarito@gmail.com Signed-off-by: Sasha Levin commit 1b244c3ef4a49407303408909ffd99ea6017aed4 Author: Timur Tabi Date: Thu Apr 30 17:38:35 2026 -0500 drm/nouveau/bios: specify correct display fuse register for Ampere and Ada [ Upstream commit c1cf2d5db80ce91a85855bbaf4da85ff603e089a ] The NV_FUSE_STATUS_OPT_DISPLAY register is used to determine whether the GPU has display hardware. The current code that normally reads this register is instead hard-coded to check for GA100 vs later GPUs. Since this function is called only on pre-Hopper GPUs, and this if-statement applies only to GA100 and later, the check works because GA100 is the only non-display Ampere and Ada GPU. However, there actually is a register that can be read, so we should use it. Fixes: a34632482f1e ("drm/nouveau/bios/ga10[024]: initial support") Signed-off-by: Timur Tabi Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260430223838.2530778-8-ttabi@nvidia.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 401319f74bcf5e2289dacfb00d2c1a10466b541e Author: Mikko Perttunen Date: Tue Apr 21 13:02:37 2026 +0900 drm/tegra: Fix iommu_map_sgtable() return value check [ Upstream commit b3f349517de8f4469c385ebb7bfdfcc148790c0f ] Commit "iommu: return full error code from iommu_map_sg[_atomic]()" changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. Update tegra_bo_iommu_map() to correctly check for errors from iommu_map_sgtable. Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421-iommu_map_sgtable-return-v1-2-fb484c07d2a1@nvidia.com Signed-off-by: Sasha Levin commit e024c7993d839503d6c1f0044b8fc537c30300e9 Author: Mikko Perttunen Date: Tue Apr 21 13:02:36 2026 +0900 gpu: host1x: Fix iommu_map_sgtable() return value check [ Upstream commit 18f74762013a4b6aa6f905c4459e0f506f9c5c7b ] Commit "iommu: return full error code from iommu_map_sg[_atomic]()" changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. pin_job() also was incorrectly assigning to 'int', which could cause overflows into negative values. Update pin_job() to correctly check for errors from iommu_map_sgtable. Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421-iommu_map_sgtable-return-v1-1-fb484c07d2a1@nvidia.com Signed-off-by: Sasha Levin commit 499603f530d2b7aac24be413a8f5279ae9b11826 Author: Felix Gu Date: Wed Jan 28 00:43:10 2026 +0800 drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output() [ Upstream commit 63a3998d792ab5c45304bf879e385a31fa923b61 ] The of_for_each_phandle() macro increments the reference count of the device node it iterates over. If the loop exits early, the reference must be released manually. In tegra_dc_has_output(), the function returns true immediately when a match is found, failing to release the current node's reference. Fix this by adding a call to of_node_put() before returning from the loop. Fixes: c57997bce423 ("drm/tegra: sor: Add Tegra186 support") Signed-off-by: Felix Gu Acked-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260128-dc-v1-1-a88205826301@gmail.com Signed-off-by: Sasha Levin commit 461192271ea621a8090bdf313c379678856575fe Author: Felix Gu Date: Thu Apr 16 20:09:29 2026 +0800 gpu: host1x: mipi: Fix device_node reference leak in tegra_mipi_request() [ Upstream commit b217fb77ca4fd0cc267329500b291c0ad8f8b211 ] In tegra_mipi_request(), when provider.np is not equal with args.np, it returns without calling of_node_put(args.np), causing a reference leak. Convert to use the existing goto out pattern to ensure proper cleanup. Fixes: 767598d447aa ("gpu: host1x: mipi: Update tegra_mipi_request() to be node based") Signed-off-by: Felix Gu Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260416-mipi-v1-1-9c027175abdf@gmail.com Signed-off-by: Sasha Levin commit 1efaea78135e61a91f69a3661f14451c66bea6c0 Author: Thomas Zimmermann Date: Tue Apr 21 09:29:05 2026 +0200 drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info [ Upstream commit d23bd83f3e47a928e783c0d6a004737519dc77dc ] That field already contains the value being assigned. No need to do this twice. Signed-off-by: Thomas Zimmermann Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Cc: linux-tegra@vger.kernel.org Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421073646.144712-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit df63c76f9c8d881ca7bce1aecfba512328d0527d Author: Mikko Perttunen Date: Fri May 15 11:34:51 2026 +0900 gpu: host1x: Allow entries in BO caches to be freed [ Upstream commit 3cbf5e3c46e66d9b3b6b91099bb720c6cb1be3bc ] When a buffer object is pinned via host1x_bo_pin() with a cache, the resulting mapping is kept in the cache so it can be reused on subsequent pins. Each mapping held a reference to the underlying host1x_bo (taken in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached, the bo itself could not be freed. However, the only way to remove the cached mapping was through the free path of the buffer object. This meant that if a bo got cached, it could never get freed again. Resolve the circularity by holding a weak reference to the bo from the cache side. This is done by having the .pin callbacks not bump the bo's refcount -- instead the common Host1x bo code does so, except for the cache reference. Also move the remove-cache-mapping-on-free code into a common function inside Host1x code. This is only called from the TegraDRM GEM buffers since those are the only ones that can be cached at the moment. Reported-by: Aaron Kling Fixes: 1f39b1dfa53c ("drm/tegra: Implement buffer object cache") Signed-off-by: Mikko Perttunen Tested-by: Aaron Kling Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260515-host1x-bocache-leak-v1-1-a0375f68aeab@nvidia.com Signed-off-by: Sasha Levin commit b3df1a2891325cd34b0059eaf0781df6c0f94cc9 Author: Ion Agorria Date: Sun May 17 12:14:50 2026 +0300 drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove [ Upstream commit ace01e2af3871343d700fb60c6f64d8f8e3180e1 ] The current power management configuration causes GR2G/GR3D to malfunction after resume. Reconfigure all PM actions to be handled within the GR*D probe and remove operations to address this. Fixes: 62fa0a985e2c ("drm/tegra: Enable runtime PM during probe") Acked-by: Mikko Perttunen Signed-off-by: Ion Agorria Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260517091450.46728-3-clamor95@gmail.com Signed-off-by: Sasha Levin commit 3055292b8eed69553b389a609197a241df47e68e Author: Svyatoslav Ryhel Date: Sun May 17 12:14:49 2026 +0300 drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered [ Upstream commit c4ef5ba1131346159e31f4ef858525cf377380a6 ] The host1x_client_register() function is called just prior to register map initialization loop, making the device available to userspace. This may result in userspace attempting to submits a job before the register map is initialized. Address this by moving register initialization before host1x client registration. Acked-by: Mikko Perttunen Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260517091450.46728-2-clamor95@gmail.com Stable-dep-of: ace01e2af387 ("drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove") Signed-off-by: Sasha Levin commit 78fcd6c3da86a3bf3799172c160841f02d9b8a71 Author: Tomas Glozar Date: Tue May 26 12:25:20 2026 +0200 rtla/actions: Restore continue flag in actions_perform() [ Upstream commit dd520daffbc901f10d49a51a58313547d417b506 ] Currently, actions_perform() only ever sets the continue flag (when performing the continue action), but never resets it. That leads to RTLA continuing tracing even if the continue action was not performed in the current iteration. For example, the following command: $ rtla timerlat hist -T 100 --on-threshold shell,command=' echo Spike! if [ -f /tmp/a ] then exit 1 else touch /tmp/a fi' --on-threshold continue should print Spike! at most once, because after hitting the threshold for the first time, /tmp/a exists, the shell action will fail, and the continue action is not performed. However, unless /tmp/a exists before the measurement, it will print Spike! until stopped, as the continue flag stays set. Set the continue flag to false in the beginning of actions_perform() to make RTLA continue only if the action was actually performed. Fixes: 8d933d5c89e8 ("rtla/timerlat: Add continue action") Link: https://lore.kernel.org/r/20260526102523.2662391-1-tglozar@redhat.com [ correct Fixes tag to include 12 characters of hash ] Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 690c798e73dc5f8ab13067c686bd30ef1c603dfc Author: Linus Walleij Date: Sat Feb 28 01:05:44 2026 +0100 dt-bindings: vendor-prefixes: Add Verbatim Corporation [ Upstream commit 4b8c63c6a2811c23995c5d8cc8bb63d26caab299 ] Verbatim Corporation has manufactured a few electronics items over the years. Link: https://en.wikipedia.org/wiki/Verbatim_(company) Acked-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 42ba8cc3047d8ac3d1d4ccdc10d846be9786d91b Author: Jackie Dong Date: Wed May 27 21:03:53 2026 +0800 ALSA: hda/realtek:ALC269 fixup for Yoga Pro 7 15ASH11 mic mute LED [ Upstream commit 17065203e1bc7e7f2786998d532cd93a06265156 ] Lenovo Yoga Pro 7 15ASH11 with AMD RYZEN AI MAX+ 388 (Strix Halo, ACP 7.0) uses Realtek ALC287 series codec. The ALC269_FIXUP_LENOVO_XPAD_ACPI in alc269_fixup_vendor_tbl[] can load lenovo_wmi_hotkey_utilities module by default in this laptop, but the driver doesn't control mic mute LED. If users run below command and the mic mute LED can work normally. $sudo echo 'Capture Switch' >/sys/class/sound/ctl-led/mic/card1/attach After added the SND_PCI_QUIRK quirk special for Lenovo Yoga Pro 7 15ASH11, the mic mute LED works well. Fixes: 83dca2530fb3 ("ALSA: hda/realtek: ALC269 fixup for Lenovo Yoga Pro 7 15ASH111 audio") Signed-off-by: Jackie Dong Link: https://patch.msgid.link/20260527130353.5658-1-xy-jackie@139.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cda919720774fa7dd01b1c11812645caf195ddbd Author: Vasant Hegde Date: Sun May 17 12:29:25 2026 +0000 iommu/amd: Fix premature break in init_iommu_one() [ Upstream commit 283d245468a2b61c41aa8b582f25ed5615d1c304 ] In init_iommu_one(), when processing IOMMU EFR attributes, the code checks whether GASUP is enabled. If GASUP is not enabled, the code falls back to legacy guest IR mode and then breaks out of the switch statement. This break incorrectly skips the subsequent initialization steps that follow the GASUP check. These initializations are independent of GASUP support and must always be performed. Fix this by replacing the early break with a conditional else block, ensuring that the XTSUP check is only skipped when GASUP is not available. Fixes: a44092e326d4 ("iommu/amd: Use IVHD EFR for early initialization of IOMMU features") Reported-by: Sudheer Dantuluri Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3fa6fb5d771c992ebedbfa7331c6bcc6f33f89b7 Author: Jiayuan Chen Date: Tue May 26 10:55:29 2026 +0800 net/sched: cls_bpf: prevent unbounded recursion in offload rollback [ Upstream commit 27db54b90bcc7c37867fe664107fa25ea6a116e4 ] Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u Fixes: 102740bd9436 ("cls_bpf: fix offload assumptions after callback conversion") Reviewed-by: Jakub Kicinski Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260526025529.24382-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc920c0659cdea5afd8721c1155a51564859e075 Author: Eric Dumazet Date: Tue May 26 14:55:28 2026 +0000 ipv6: guard against possible NULL deref in __in6_dev_stats_get() [ Upstream commit 507541c2a8eeb76c02bd2511958f73a8cfa3e1bc ] dev_get_by_index_rcu() could return NULL if the original physical device is unregistered. Found by Sashiko. Fixes: e1ae5c2ea478 ("vrf: Increment Icmp6InMsgs on the original netdev") Signed-off-by: Eric Dumazet Cc: Stephen Suryaputra Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260526145529.3587126-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2898b3f3dc4faf1aeea43219b91118f4fcf26872 Author: Breno Leitao Date: Sun May 24 08:19:56 2026 -0700 workqueue: drop spurious '*' from print_worker_info() fn declaration [ Upstream commit 611583a76ea97991b0f65ec1ff099eac7fe0bae4 ] print_worker_info() declares its local 'fn' as work_func_t * but worker->current_func has type work_func_t (a function pointer). The extra level of indirection is wrong and only happens to be harmless today because every supported Linux architecture has sizeof(work_func_t) == sizeof(work_func_t *): copy_from_kernel_nofault() reads the correct number of bytes by accident, and %ps still resolves the printed address because the stored value is the function address regardless of declared type. On any future ABI where sizeof(void (*)()) differs from sizeof(void *), the nofault copy would transfer the wrong number of bytes and the subsequent %ps would print an incorrect address. Match the field type so the intent is explicit and the code does not silently rely on equal pointer sizes. Fixes: 3d1cb2059d93 ("workqueue: include workqueue info when printing debug dump of a worker task") Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit fa9b6accd1ad7af6914b409c6b003c417724c299 Author: Mateusz Nowicki Date: Sat May 23 08:28:16 2026 +0000 nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools [ Upstream commit a192b8cfa447e1b3701a13434a31c392b2e7ed29 ] nvme_setup_descriptor_pools() indexes dev->descriptor_pools[] using the numa_node forwarded from hctx->numa_node by its single caller, nvme_init_hctx_common(). On a non-NUMA kernel hctx->numa_node is NUMA_NO_NODE (-1). Because the parameter was declared 'unsigned', the value becomes UINT_MAX and the index walks off the array (sized to nr_node_ids), faulting during nvme_alloc_ns() and leaving the namespace without a /dev node. Reproduces on any NVMe controller probed by a CONFIG_NUMA=n kernel: BUG: unable to handle page fault for address: ffff889101603d38 RIP: 0010:nvme_init_hctx_common+0x5a/0x190 [nvme] Call Trace: nvme_init_hctx+0x10/0x20 [nvme] nvme_alloc_ns+0x9e/0xa10 [nvme_core] nvme_scan_ns+0x301/0x3b0 [nvme_core] nvme_scan_ns_async+0x23/0x30 [nvme_core] Switch the parameter to int and fall back to node 0 when it is NUMA_NO_NODE; node 0 is always present. Fixes: d977506f8863 ("nvme-pci: make PRP list DMA pools per-NUMA-node") Link: https://lore.kernel.org/r/20260309062840.2937858-2-iam@sung-woo.kim Reported-by: Sung-woo Kim Reviewed-by: Christoph Hellwig Signed-off-by: Mateusz Nowicki Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 7173a741fed73de6247384056fe92e582ba12507 Author: Nilay Shroff Date: Wed May 27 11:50:00 2026 +0530 nvme-multipath: fix flex array size in struct nvme_ns_head [ Upstream commit 001e57554de81aa79c25c18fd53911d8a415c304 ] struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs. Fixes: f333444708f8 ("nvme: take node locality into account when selecting a path") Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Hannes Reinecke Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 22aa70f9a0544643ec37d442b6fcb1833d804462 Author: Geliang Tang Date: Tue May 26 17:28:05 2026 +0800 nvmet-tcp: check return value of nvmet_tcp_set_queue_sock [ Upstream commit 7ef789703e2b91775dcb36b2efa46325be31a2a0 ] The return value of nvmet_tcp_set_queue_sock() is currently ignored in nvmet_tcp_tls_handshake_done(). If it fails (e.g., due to the socket not being in TCP_ESTABLISHED state), the socket callbacks will not be properly set, leading to queue and socket leakage. Fix this by capturing the return value and calling nvmet_tcp_schedule_release_queue() on failure to ensure proper cleanup. Fixes: 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall") Reviewed-by: Hannes Reinecke Reviewed-by: Chaitanya Kulkarni Signed-off-by: Geliang Tang Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5fbe83a374f09561a0f0c1f4aa021501ffd681eb Author: Geliang Tang Date: Tue May 26 17:22:22 2026 +0800 nvmet-tcp: fix page fragment cache leak in error path [ Upstream commit 4dae393956093c807212918fd91a8fc70df15338 ] In nvmet_tcp_alloc_queue(), when a connection is closed during the allocation process (e.g., nvmet_tcp_set_queue_sock() returns -ENOTCONN), the error handling jumps to out_destroy_sq and then to out_ida_remove without draining the page fragment cache. Although nvmet_tcp_free_cmd() is called in some error paths to release individual page fragments, the underlying page cache reference held by queue->pf_cache is never released. The first allocation using pf_cache is the call to nvmet_tcp_alloc_cmd() for queue->connect, which happens after ida_alloc() returns successfully. This results in a page leak each time a connection fails during allocation, which could lead to memory exhaustion over time if connections are repeatedly opened and closed. Fix this by calling page_frag_cache_drain() before freeing the queue structure in the out_ida_remove label. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Reviewed-by: Christoph Hellwig Signed-off-by: Geliang Tang Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 673fb7374b1b45836673ba908cc91fd165460933 Author: Jia He Date: Tue May 19 09:39:37 2026 +0000 init/initramfs_test: wait_for_initramfs() before running [ Upstream commit ec3f4e0443a61e68092ac07111f16dd4ca89ddb4 ] initramfs_test_extract() and friends call unpack_to_rootfs() from a kunit kthread while do_populate_rootfs() may still be running asynchronously from rootfs_initcall. unpack_to_rootfs() keeps its parser state in module-static variables (victim, byte_count, state, this_header, header_buf, name_buf, ...), so the two writers corrupt each other. On arm64 v7.0-rc5+ this oopses early in boot: Unable to handle kernel paging request at virtual address ffff80018f9f0ffc pc : do_reset+0x3c/0x98 Call trace: do_reset initramfs_test_extract kunit_try_run_case Initramfs unpacking failed: junk within compressed archive do_reset() faults because 'victim' was overwritten by the boot-time unpacker; the boot unpacker meanwhile logs the bogus "junk within compressed archive" on the real initrd because the test wrecked its state machine. Add a .suite_init callback that calls wait_for_initramfs() so the async unpack is quiescent before the first case runs. suite_init runs once per suite rather than before every individual test case. Fixes: 83c0b27266ec ("initramfs_test: kunit tests for initramfs unpacking") Signed-off-by: Jia He Link: https://patch.msgid.link/20260519093937.1064628-1-justin.he@arm.com Reviewed-by: David Disseldorp Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit adde45911310511b298f479dea0a743683e0eefb Author: Charles Keepax Date: Fri May 8 15:34:53 2026 +0100 pinctrl: cs42l43: Fix polarity on debounce [ Upstream commit 9da52ee80aee3ab3c69208bd1cfbb4be01371214 ] The debounce bit sets a bypass on the debounce rather than enabling it, as such the current polarity of the debounce is set incorrectly. Invert the polarity to correct this. Fixes: d5282a539297 ("pinctrl: cs42l43: Add support for the cs42l43") Signed-off-by: Charles Keepax Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6d497a3f2fa6f28aba2330ae2a83945baa5253a1 Author: Charles Keepax Date: Fri May 8 15:34:52 2026 +0100 pinctrl: cs42l43: Fix leaked pm reference on error path [ Upstream commit 1cb73b83ab6dec8159d0280345a46fbb282c378f ] Returning directly if the regmap_update_bits() fails causes a pm runtime reference to be leaked, let things run to the end of the function instead. Fixes: e52c741907fb ("pinctrl: cirrus: cs42l43: use new GPIO line value setter callbacks") Signed-off-by: Charles Keepax Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4b6e404257b8a63d0446785bf925ef4f31e495d6 Author: Joey Lu Date: Mon May 11 11:17:49 2026 +0800 pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table [ Upstream commit ce4e27247ca643645c6d3043aad1c1c67bf7fdac ] Each GPIO bank has two 32-bit MFP registers: MFPL covering pins 0-7 at the bank base offset, and MFPH covering pins 8-15 at base offset+4. ma35_pinctrl_parse_groups() computed the register address without accounting for this split, so any pin with an index >= 8 within its bank was written to the wrong register. Also fix the pin descriptor table in pinctrl-ma35d1.c: switch from sequential to 16-per-bank pin numbering, add missing PC8-PC11 pins and their mux options, and remove the duplicate PN10-PN15 entries. Fixes: f805e356313b ("pinctrl: nuvoton: Add ma35d1 pinctrl and GPIO driver") Signed-off-by: Joey Lu Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6824e4fdb2f718f7f1d79e5aece81cc969dd9404 Author: Florian Schmaus Date: Tue May 26 10:01:08 2026 +0200 selftests: Fix Makefile target for nsfs [ Upstream commit 77d1a2d2318fa96f8a662c9ad6647abedcd22734 ] The kselftests for nsfs where moved under filesystem/ with commit cae73d3bdce5 ("seltests: move nsfs into filesystems subfolder"). However, the kselftest TARGETS declaration was not adjusted. Since the kselftest Makefile ignores errors unless no target builds, the invalid target declaration can easily be missed. Fix this by adjusting the TARGETS accordingly. Fixes: cae73d3bdce5 ("seltests: move nsfs into filesystems subfolder") Signed-off-by: Florian Schmaus Link: https://patch.msgid.link/20260526-kselftest-nsfs-v1-1-7b042ebe42d6@geekplace.eu Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit d6fd2afb137f52bf00c5210cc44d08ed54dcffb4 Author: Zhang Cen Date: Wed May 27 14:29:48 2026 +0800 ALSA: seq: midi: Serialize output teardown with event_input [ Upstream commit ef7607ab1c8adc6258fb1b27d08e26aecdc18a58 ] event_process_midi() borrows msynth->output_rfile.output and then passes the substream to dump_midi() and snd_rawmidi_kernel_write() without synchronizing with the output open/close transition. midisynth_use() also publishes output_rfile before snd_rawmidi_output_params() has finished. The last midisynth_unuse() can therefore release the same rawmidi file and free substream->runtime before snd_rawmidi_kernel_write1() takes its runtime buffer reference. That leaves the event_input path using a stale substream or runtime and can end in a NULL-deref or use-after-free. Fix this with two pieces of synchronization. Keep a short IRQ-safe spinlock only for publishing or clearing output_rfile and for pairing the output snapshot with an snd_use_lock_t reference. Once event_process_midi() has taken that in-flight reference, it drops the spinlock before calling snd_seq_dump_var_event(), dump_midi(), or snd_rawmidi_kernel_write(). midisynth_unuse() now detaches the visible rawmidi file under the same spinlock, waits for the in-flight writers to drain, and only then drains and releases the saved file. midisynth_use() likewise opens into a local snd_rawmidi_file and publishes it only after snd_rawmidi_output_params() succeeds. The buggy scenario involves two paths, with each column showing the order within that path: event_input path: last unuse path: 1. event_process_midi() snapshots 1. midisynth_unuse() starts output_rfile.output. tearing down output_rfile. 2. dump_midi() reaches 2. snd_rawmidi_kernel_release() snd_rawmidi_kernel_write() closes the output file. before runtime is pinned. 3. close_substream() frees 3. The callback keeps using substream->runtime. the borrowed substream. Validation reproduced this kernel report: KASAN null-ptr-deref in snd_rawmidi_kernel_write1+0x56/0x360 RIP: 0033:0x7fde7dd0837f RIP: 0010:snd_rawmidi_kernel_write1+0x56/0x360 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Link: https://patch.msgid.link/20260527062948.3614025-1-rollkingzzc@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7aad70cabd8f34cf11a9593fcd3f2ac3f5496943 Author: Takashi Iwai Date: Tue May 26 17:28:41 2026 +0200 ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data [ Upstream commit 7c349b4f2a603202fb8c363bd2774a22ac2fddf3 ] The OSS sequencer processes the input MIDI bytes into a sequencer event to be dispatched later (in snd_seq_oss_midi_putc() called from snd_seq_oss_process_event()). When it's a SysEx data, the event record contains data.ext.ptr pointer to the original SysEx bytes, and the referred data is copied into the pool afterwards at dispatching. The problem is that, if the sequencer port gets closed concurrently before the dispatch, the OSS sequencer core also releases the resources (in snd_seq_oss_midi_check_exit_port()), while the pending event may hold a stale pointer, eventually leading to a UAF at a later dispatch. Fortunately, there is already a refcounting mechanism (snd_use_lock_t) for the OSS MIDI device access, and for addressing the issue above, we just need to extend the refcount until the event gets dispatched. This patch extends snd_seq_oss_process_event() to give back the refcount object, which is in turn released after calling the sequencer dispatcher with the given event in the caller side. According to the original report, KASAN report as below: KASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470 RIP: 0033:0x7f2cb66a6340 Read of size 6 Call trace: dump_stack_lvl+0x73/0xb0 (?:?) print_report+0xd1/0x650 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x1a7/0x340 (?:?) kasan_complete_mode_report_info+0x64/0x200 (?:?) kasan_report+0xf7/0x130 (?:?) snd_seq_event_dup+0x40c/0x470 (?:?) kasan_check_range+0x10c/0x1c0 (?:?) __asan_memcpy+0x27/0x70 (?:?) snd_seq_event_dup+0x9/0x470 (?:?) snd_seq_client_enqueue_event+0x139/0x240 (?:?) _raw_spin_unlock_irqrestore+0x4b/0x60 (?:?) snd_seq_kernel_client_enqueue+0x102/0x120 (?:?) snd_seq_oss_write+0x416/0x4e0 (?:?) apparmor_file_permission+0x20/0x30 (?:?) odev_write+0x3b/0x60 (?:?) vfs_write+0x1ce/0x850 (?:?) lock_release+0xc8/0x2a0 (?:?) __kasan_check_write+0x18/0x20 (?:?) __mutex_unlock_slowpath+0x129/0x510 (?:?) ksys_write+0xe1/0x180 (?:?) mutex_unlock+0x16/0x20 (?:?) odev_ioctl+0x65/0xc0 (?:?) __x64_sys_write+0x46/0x60 (?:?) x64_sys_call+0x7d/0x20d0 (?:?) do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: Zhang Cen Closes: https://lore.kernel.org/20260521233900.478153-1-rollkingzzc@gmail.com Link: https://patch.msgid.link/20260526152843.617503-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 05f62f9d6ab404979b9e3349637a6e00a12a6ff7 Author: Cássio Gabriel Date: Tue May 26 09:48:27 2026 -0300 ALSA: xen-front: Connect event channel after stream prepare [ Upstream commit 3624f0bd4af15a820b1bd88b489980fa9fd61b7a ] The request channel must be connected from ALSA .open(), because hw-rule queries and the stream open request use it. The event channel is different: XENSND_EVT_CUR_POS handling uses ALSA runtime buffer and period geometry, and the corresponding Xen stream parameters are not submitted to the backend until .prepare() sends XENSND_OP_OPEN. Currently .open() connects both channels. A backend current-position event, or a stale event queued for an earlier stream instance, can therefore reach xen_snd_front_alsa_handle_cur_pos() before runtime->buffer_size and runtime->period_size are valid. Add a per-channel connection helper, connect only the request channel in .open(), connect the event channel after a successful stream prepare, and disconnect it before stream close/free. Re-check the event-channel state after taking ring_io_lock so disconnecting the event channel synchronizes against a threaded IRQ that passed the initial lockless state test. Keep defensive runtime geometry checks in the position handler. Fixes: 1cee559351a7 ("ALSA: xen-front: Implement ALSA virtual sound driver") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260526-alsa-xen-event-channel-fixes-v1-2-91d3a6a50778@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b1ff4649fa5a1170b8da47303b07ed0e8f4968d0 Author: Cássio Gabriel Date: Tue May 26 09:48:26 2026 -0300 ALSA: xen-front: Reset event channel state on stream clear [ Upstream commit 9cd81152373c560b8aa8299b0705c4db82b103b7 ] xen_snd_front_evtchnl_pair_clear() resets evt_next_id for both channels. That is correct for the request channel, where evt_next_id is used to allocate the next request id. It is wrong for the event channel: incoming events are validated against evt_id, and evt_id is incremented by evtchnl_interrupt_evt(). This leaves the expected event id from the previous stream instance. A backend that restarts event ids for a reopened stream can then have valid current-position events dropped until the stale frontend id catches up. Reset evt_id for the event channel. Also advance the event-page consumer to the current producer while clearing the stream, so obsolete events queued for the previous stream instance are not delivered to the next ALSA runtime. Fixes: 1cee559351a7 ("ALSA: xen-front: Implement ALSA virtual sound driver") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260526-alsa-xen-event-channel-fixes-v1-1-91d3a6a50778@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 97f35b0a523d1668a24e204372134e62289a320f Author: Zhongqiu Han Date: Sun Apr 19 21:26:54 2026 +0800 cpufreq: governor: Fix stale prev_cpu_nice spike when enabling ignore_nice_load [ Upstream commit 24fc5870808dea4290e9563746cb5f2146043c6c ] When ignore_nice_load is toggled from 0 to 1 via sysfs, dbs_update() may run concurrently and observe the new tunable value while prev_cpu_nice still holds a stale baseline, producing a spurious massive idle_time that results in an incorrect CPU load value. The race can be illustrated with two concurrent paths: Path A (sysfs write, holds attr_set->update_lock): governor_store() mutex_lock(&attr_set->update_lock) ignore_nice_load_store() dbs_data->ignore_nice_load = 1 /* (A1) */ gov_update_cpu_data(dbs_data) mutex_lock(&policy_dbs->update_mutex) /* (A2) */ j_cdbs->prev_cpu_nice = kcpustat_field(...) mutex_unlock(&policy_dbs->update_mutex) mutex_unlock(&attr_set->update_lock) Path B (work queue, wins the race between A1 and A2): dbs_work_handler() mutex_lock(&policy_dbs->update_mutex) /* acquired before A2 */ dbs_update() ignore_nice = dbs_data->ignore_nice_load /* sees new value: 1 */ cur_nice = kcpustat_field(...) idle_time += div_u64(cur_nice - j_cdbs->prev_cpu_nice, ..) /* stale */ j_cdbs->prev_cpu_nice = cur_nice mutex_unlock(&policy_dbs->update_mutex) Fix this by unconditionally sampling cur_nice and advancing prev_cpu_nice in dbs_update() on every call, regardless of ignore_nice. With prev_cpu_nice always reflecting the most recent sample, enabling ignore_nice_load can never produce a stale-baseline spike: the delta will always be the nice time accumulated in the last sampling interval, not since boot. The additional kcpustat_field() call per CPU per sample is negligible given that the sampling path already reads idle and load accounting. To keep prev_cpu_nice handling consistent with the always-tracking semantics introduced above: - gov_update_cpu_data() unconditionally resets prev_cpu_nice alongside prev_cpu_idle, so both baselines share the same timestamp when io_is_busy changes. This prevents an interval mismatch between idle_time and nice_delta on the next dbs_update() when ignore_nice_load is enabled. - cpufreq_dbs_governor_start() unconditionally initializes prev_cpu_nice so the baseline is always valid from the first dbs_update() call; remove the ignore_nice guard and the now-unused ignore_nice variable. Fixes: ee88415caf736b ("[CPUFREQ] Cleanup locking in conservative governor") Fixes: 5a75c82828e7c0 ("[CPUFREQ] Cleanup locking in ondemand governor") Fixes: 326c86deaed54a ("[CPUFREQ] Remove unneeded locks") Signed-off-by: Zhongqiu Han Link: https://patch.msgid.link/20260419132655.3800673-3-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit daf480c6fe154e2d03ef693fec8b2487adc3744c Author: Zhongqiu Han Date: Sun Apr 19 21:26:53 2026 +0800 cpufreq: governor: Fix data races on per-CPU idle/nice baselines [ Upstream commit 91f5d698478f3d07230cf9ca4dfaf67e0316a53d ] gov_update_cpu_data() resets per-CPU prev_cpu_idle for every CPU in the governed domain, and conditionally resets prev_cpu_nice when ignore_nice_load is set. It is called from sysfs store callbacks (e.g. ignore_nice_load_store) which run under attr_set->update_lock, held by the surrounding governor_store(). Concurrently, dbs_work_handler() calls gov->gov_dbs_update() (which calls dbs_update()) under policy_dbs->update_mutex. dbs_update() both reads and writes the same prev_cpu_idle / prev_cpu_nice fields. The potential race path is: Path A (sysfs write, holds attr_set->update_lock only): governor_store() mutex_lock(&attr_set->update_lock) ignore_nice_load_store() dbs_data->ignore_nice_load = input gov_update_cpu_data(dbs_data) list_for_each_entry(policy_dbs, ...) for_each_cpu(j, ...) j_cdbs->prev_cpu_idle = get_cpu_idle_time(...) /* write */ j_cdbs->prev_cpu_nice = kcpustat_field(...) /* write */ mutex_unlock(&attr_set->update_lock) Path B (work queue, holds policy_dbs->update_mutex only): dbs_work_handler() mutex_lock(&policy_dbs->update_mutex) gov->gov_dbs_update(policy) dbs_update() for_each_cpu(j, policy->cpus) idle_time = cur - j_cdbs->prev_cpu_idle /* read */ j_cdbs->prev_cpu_idle = cur_idle_time /* write */ idle_time += cur_nice - j_cdbs->prev_cpu_nice /* read */ j_cdbs->prev_cpu_nice = cur_nice /* write */ mutex_unlock(&policy_dbs->update_mutex) Because attr_set->update_lock and policy_dbs->update_mutex are two completely independent locks, the two paths are not mutually exclusive. This results in a data race on cpu_dbs_info.prev_cpu_idle and cpu_dbs_info.prev_cpu_nice. Fix this by also acquiring policy_dbs->update_mutex in gov_update_cpu_data() for each policy, so that path A participates in the mutual exclusion already established by dbs_work_handler(). Also update the function comment to accurately reflect the two-level locking contract. Additionally, cpufreq_dbs_governor_start() initializes prev_cpu_idle using io_busy read from dbs_data->io_is_busy without holding policy_dbs->update_mutex. A concurrent io_is_busy_store() can update io_is_busy and call gov_update_cpu_data(), which writes prev_cpu_idle with the new value under the mutex. cpufreq_dbs_governor_start() then overwrites prev_cpu_idle with the stale io_busy value, leaving the baseline inconsistent with the tunable. Fix this by reading io_busy inside the mutex. The root of this race dates back to the original ondemand/conservative governors. Before commit ee88415caf73 ("[CPUFREQ] Cleanup locking in conservative governor") and commit 5a75c82828e7 ("[CPUFREQ] Cleanup locking in ondemand governor"), all accesses to prev_cpu_idle and prev_cpu_nice in cpufreq_governor_dbs() (path X), store_ignore_nice_load() /io_is_busy_store() (path Y), and do_dbs_timer() (path Z) were serialised by the same dbs_mutex, so no race existed. Those two commits switched do_dbs_timer() from dbs_mutex to a per-policy/per-cpu timer_mutex to reduce lock contention, but left path Y (store) still holding dbs_mutex. As a result, path Y (store) and path Z (do_dbs_timer) no longer shared a common lock, introducing a potential race on prev_cpu_idle/prev_cpu_nice between path Y (store) and dbs_check_cpu(). Commit 326c86deaed54a ("[CPUFREQ] Remove unneeded locks") then removed dbs_mutex from store_ignore_nice_load()/io_is_busy_store() entirely, introducing an additional potential race between path Y (now lockless) and cpufreq_governor_dbs() (path X, still holding dbs_mutex), while the race between path Y and path Z remained. Fixes: ee88415caf736b ("[CPUFREQ] Cleanup locking in conservative governor") Fixes: 5a75c82828e7c0 ("[CPUFREQ] Cleanup locking in ondemand governor") Fixes: 326c86deaed54a ("[CPUFREQ] Remove unneeded locks") Signed-off-by: Zhongqiu Han Link: https://patch.msgid.link/20260419132655.3800673-2-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e392eafcc2f843f14b532a8984edf86027033064 Author: Ripan Deuri Date: Wed May 20 00:58:15 2026 +0530 wifi: ath12k: fix error unwind on arch_init() failure in PCI probe [ Upstream commit d5c336161088c588f85da64f48ba6deead194afd ] When arch_init() fails in ath12k_pci_probe(), the code jumps to err_pci_msi_free, leaking resources in teardown. Redirect the failure path to err_free_irq so teardown matches the setup order. Compile-tested only. Fixes: 614c23e24ee8 ("wifi: ath12k: Support arch-specific DP device allocation") Signed-off-by: Ripan Deuri Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260519192815.3911324-1-ripan.deuri@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 6d5dbd41ae1d5fbe28aa17f00c2a1aaecb041992 Author: Miquel Raynal Date: Tue May 26 16:56:27 2026 +0200 mtd: spi-nor: Drop duplicate Kconfig dependency [ Upstream commit a6470e2162e9c3779a4bd6ff3bed1b81d796e46e ] I do not think the MTD dependency is needed twice. This is likely a duplicate coming from a former rebase when the spi-nor core got cleaned up a while ago. Remove the extra line. Fixes: b35b9a10362d ("mtd: spi-nor: Move m25p80 code in spi-nor.c") Signed-off-by: Miquel Raynal Reviewed-by: Michael Walle Signed-off-by: Pratyush Yadav Signed-off-by: Sasha Levin commit 71304ef1ffe188725e7030356d0be5b2cfca76cf Author: Miquel Raynal Date: Tue May 26 16:56:25 2026 +0200 mtd: spi-nor: debugfs: Fix the flags list [ Upstream commit 829dff83597615208aedf0f5abb3878b47f2314d ] As mentioned above the spi_nor_option_flags enumeration in core.h, this list should be kept in sync with the one in the core. Add the missing flag. Fixes: 6a42bc97ccda ("mtd: spi-nor: core: Allow specifying the byte order in Octal DTR mode") Reviewed-by: Michael Walle Signed-off-by: Miquel Raynal Signed-off-by: Pratyush Yadav Signed-off-by: Sasha Levin commit d9aa1b2d79524802da5a840e6c867e13203b1e5d Author: Jon Hunter Date: Tue May 19 09:47:06 2026 +0100 arm64: tegra: Fix address of Tegra264 main GPIO controller [ Upstream commit 7f2eeae12690aaee6195f85ed129a29c17f156d1 ] The 64-bit address of the main GPIO controller on Tegra264 is 0x810c300000. The main GPIO controller was incorrectly added under the bus@0 node instead of the bus@8100000000 node breaking the boot on Tegra264. Fix this by moving to main GPIO controller node under bus@8100000000. Fixes: c70e6bc11d20 ("arm64: tegra: Add Tegra264 GPIO controllers") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 4f72ebf36e72cb28c659f54340f92f81cf7b1deb Author: Danilo Krummrich Date: Mon May 25 03:23:22 2026 +0200 driver core: Guard deferred probe timeout extension with delayed_work_pending() [ Upstream commit 557495bc879013c3d5e21d667e987e7ce3a514de ] mod_delayed_work() unconditionally queues the work even when it wasn't previously pending, which can fire the timeout prematurely or restart it after it already fired. Add a delayed_work_pending() guard to restore the originally intended semantics. Premature firing calls fw_devlink_drivers_done() before all built-in drivers have registered, causing fw_devlink to prematurely relax device links for suppliers whose drivers haven't loaded yet. Fixes: 1137838865bf ("driver core: Use mod_delayed_work to prevent lost deferred probe work") Tested-by: Geert Uytterhoeven Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260525012340.3860581-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 3890afc64cb5afd321eab9206b773ab9c6aa7bcb Author: Danilo Krummrich Date: Mon May 25 03:23:21 2026 +0200 driver core: Fix missing jiffies conversion in deferred_probe_extend_timeout() [ Upstream commit f9e6da99fe49277979798a1c3b9790ae10aaa18a ] mod_delayed_work() takes jiffies, not seconds. Thus, restore the dropped conversion. While at it, fix incorrect indentation. Fixes: 1137838865bf ("driver core: Use mod_delayed_work to prevent lost deferred probe work") Tested-by: Biju Das Tested-by: Geert Uytterhoeven Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260525012340.3860581-1-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 4f65b01eb631b9307ca6c7e7f4aec29460eaeacf Author: Rosen Penev Date: Fri May 8 20:57:27 2026 -0700 mips: n64: add __iomem for writel call [ Upstream commit 579f5329d5df2dbcf4bb5ef398701c2501d24892 ] sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *mem @@ got unsigned int [usertype] * Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202105261445.AcvPd2EE-lkp@intel.com/ Fixes: baec970aa5ba ("mips: Add N64 machine type") Signed-off-by: Rosen Penev Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 9a092e2d344fd60076a5a23bdb081a74395bc883 Author: Rosen Penev Date: Thu May 7 21:27:24 2026 -0700 mips: ralink: mt7621: add missing __iomem [ Upstream commit 4ddaf88aadd3bd09c2eb3734c53d2864af6b144e ] raw_readl and writel calls expect pointers annotated with __iomem. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild/202211060456.cnV6IK6G-lkp@intel.com/ Fixes: cc19db8b312a ("MIPS: ralink: mt7621: do memory detection on KSEG1") Signed-off-by: Rosen Penev Reviewed-by: Sergio Paracuellos Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit fa403d9617310b34361317072806a3f55e333827 Author: Maciej W. Rozycki Date: Mon May 4 21:14:00 2026 +0100 MIPS: DEC: Remove do_IRQ() call indirection [ Upstream commit 35554eadc1b127bb5294504a4ac8f3a5dd9e299d ] As from commit 8f99a1626535 ("MIPS: Tracing: Add IRQENTRY_EXIT section for MIPS") do_IRQ() is not a macro anymore and can be invoked directly from assembly code, as a tail call. Remove the dec_irq_dispatch() stub then and the indirection previously introduced with commit 187933f23679 ("[MIPS] do_IRQ cleanup"), improving performance by reducing the number of control flow changes and the overall instruction count, while fixing a compiler's complaint about a missing prototype for said stub: arch/mips/dec/setup.c:780:25: warning: no previous prototype for 'dec_irq_dispatch' [-Wmissing-prototypes] 780 | asmlinkage unsigned int dec_irq_dispatch(unsigned int irq) | ^~~~~~~~~~~~~~~~ (which gets promoted to a compilation error with CONFIG_WERROR). Fixes: 8f99a1626535 ("MIPS: Tracing: Add IRQENTRY_EXIT section for MIPS") Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit cf49b4e37fda345d50eb82a1d511531d08e0347f Author: Maciej W. Rozycki Date: Sat May 2 00:14:20 2026 +0100 MIPS: Fix big-endian stack argument fetching in o32 wrapper [ Upstream commit 8e0780d30b1b51248e42895b7acc7a20f147b40b ] Fix an issue in call_o32() where the upper 32-bit half of incoming n64 stack arguments is fetched and used for outgoing o32 stack arguments on big-endian platforms. This code was adapted from arch/mips/dec/prom/call_o32.S which was meant for a little-endian platform only and therefore using 32-bit loads from 64-bit stack slot locations holding incoming stack arguments resulted in correct values being retrieved for data that is expected to be 32-bit. This works on little-endian platforms where the lower 32-bit half of the 64-bit value is located at every 64-bit stack slot location. However on big-endian platforms the lower 32-bit half is instead located at offset 4 from every 64-bit stack slot location. So to fix the issue the offset of 4 would have to be used on big-endian platforms only, or alternatively a 64-bit load from the 64-bit stack slot location can be used across the board, as the subsequent 32-bit store to the corresponding outgoing stack argument slot will correctly truncate the value and cause no unpredictable result. We already take advantage of this architectural feature for the incoming arguments held in $a6 and $a7 registers, since the o32 wrapper does not know how many incoming arguments there are and consequently propagates incoming data which may not be 32-bit. Since this code is generally supposed to be used with the stack located in cached memory there is no extra overhead expected for 64-bit loads as opposed to 32-bit ones, so pick this variant for code simplicity. Fixes: 231a35d37293 ("[MIPS] RM: Collected changes") Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5e6bc20316d0f97d5d3b07c1f444d27a3c3745ef Author: Jiakai Xu Date: Sat May 23 02:23:14 2026 +0000 PM: sleep: Use complete() in device_pm_sleep_init() [ Upstream commit 3855941f1e4069182c895d5093c5fa589f5b38bd ] Replace complete_all() with complete() in device_pm_sleep_init() to allow it to be called in atomic contexts without triggering a false-positive WARNING from lockdep_assert_RT_in_threaded_ctx() when CONFIG_PROVE_RAW_LOCK_NESTING is enabled. device_pm_sleep_init() may be called during device initialization while holding a raw_spinlock (e.g., from within device_initialize()), and complete_all() is unsafe in atomic contexts on PREEMPT_RT kernels. complete(), which is safe to call from any context, is sufficient here. complete_all() sets the completion count to UINT_MAX/2 (permanently signaled), while complete() increments it by 1. Since no threads can be waiting during device initialization, both are functionally equivalent. The completion is always reinitialized via reinit_completion() in dpm_clear_async_state() before each suspend/resume cycle. However, changing to complete() introduces a potential deadlock for devices with no PM support (dev->power.no_pm = true). Such devices are never added to the dpm_list and never go through dpm_clear_async_state(), so their completion is never reinitialized. A parent device waiting on a no_pm child across multiple suspend phases would consume the single-use token in the first phase and block forever in the second. Fix this by adding an early return in dpm_wait() when dev->power.no_pm is set, since no_pm devices do not participate in system suspend/resume. Fixes: 152e1d592071 ("PM: Prevent waiting forever on asynchronous resume after failing suspend") Signed-off-by: Jiakai Xu [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20260523022314.2657232-1-xujiakai24@mails.ucas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5a2119f4a98555c363911511d4cbe74a4757de7e Author: Xianwei Zhao Date: Mon May 18 08:26:20 2026 +0000 pinctrl: meson: amlogic-a4: fix gpio output glitch [ Upstream commit 45ad4de324cb1bba88e568b5bef633a79d926aed ] When the system transitions from bootloader to kernel, the GPIO is expected to keep driving high. However, the Linux kernel first configures the pin direction and then sets the output value. This may cause a brief low-level glitch on the GPIO line, which can be problematic for regulator control. By configuring the output value before switching the pin direction to output, the glitch can be avoided. This commit fixes the issue by swapping the configuration order. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Xianwei Zhao Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2734eb69a79601cb49be2bd36829c41aadc8beeb Author: Tao Cui Date: Wed May 20 18:45:46 2026 +0800 RDMA/counter: Fix incorrect port index in rdma_counter_init() error cleanup [ Upstream commit b86fd95805a7bd4c5b9465c9e7f75e45bbe7eb6f ] The error cleanup loop in rdma_counter_init() iterates with variable 'i' but accesses dev->port_data[port] instead of dev->port_data[i]. This causes the failed port's hstats to be freed multiple times while leaking hstats of previously initialized ports. Fixes: 56594ae1d250 ("RDMA/core: Annotate destroy of mutex to ensure that it is released as unlocked") Link: https://patch.msgid.link/r/20260520104546.1776253-3-cuitao@kylinos.cn Signed-off-by: Tao Cui Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 53b70c86e249a1c3a61aa78a84831300546d54a3 Author: Rafael J. Wysocki Date: Thu May 21 16:06:48 2026 +0200 ACPI: PAD: Fix teardown ordering in acpi_pad_remove() [ Upstream commit 5776575d9a7e50e77c45e0ab0271c000496f341d ] The ACPI notify handler installed by acpi_pad_probe() needs to be removed before calling acpi_pad_idle_cpus() in acpi_pad_remove() so it doesn't schedule idle time injection on some CPUs again. Fixes: 8e0af5141ab9 ("ACPI: create Processor Aggregator Device driver") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2064153.usQuhbGJ8B@rafael.j.wysocki Signed-off-by: Sasha Levin commit f3c9e84268e9fa613d40d6c138fb6969c35879b5 Author: Lianfa Weng Date: Wed May 20 13:57:59 2026 +0800 RDMA/hns: Fix log flood after cmd_mbox failure [ Upstream commit bbd97d71e53e551890e4115ad9de46b5f2ac0858 ] hns_roce_cmd_mbox() is the command interface between driver and hardware. When hardware is abnormal, the unlimited error printings after hns_roce_cmd_mbox() failure will cause log flood and even system crash. Replace ibdev_err() and ibdev_warn() with their ratelimited versions in the error handling path after hns_roce_cmd_mbox() (and its wrappers hns_roce_create_hw_ctx/hns_roce_destroy_hw_ctx) fails. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://patch.msgid.link/r/20260520055759.2354037-4-huangjunxian6@hisilicon.com Signed-off-by: Lianfa Weng Signed-off-by: Junxian Huang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1e56f8886d64288cf88d80af44c7b9148aeaa98b Author: Lianfa Weng Date: Wed May 20 13:57:58 2026 +0800 RDMA/hns: Fix warning in poll cq direct mode [ Upstream commit 3f19c2a3852e6ba75f3e92dd5edc4e07f3d07f4a ] CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 Fixes: f295e4cece5c ("RDMA/hns: Delete unnecessary callback functions for cq") Link: https://patch.msgid.link/r/20260520055759.2354037-3-huangjunxian6@hisilicon.com Signed-off-by: Lianfa Weng Signed-off-by: Junxian Huang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e874d99092a0307c56d260922e7c4dca7373f790 Author: Guangshuo Li Date: Mon May 18 10:19:10 2026 +0800 IB/mlx4: Fix refcount leak in add_port() error path [ Upstream commit 9a8826fdfbcd7ed2ccf745f5d54208358d939def ] After kobject_init_and_add(), the lifetime of the embedded struct kobject is expected to be managed through the kobject core reference counting. In add_port(), failure paths after kobject_init_and_add() must not free struct mlx4_port directly, because the embedded kobject is then managed by the kobject core. Freeing it directly leaves the kobject reference counting unbalanced and can lead to incorrect lifetime handling. Allocate the pkey and gid attribute arrays before kobject_init_and_add(), so failures before kobject initialization can be handled by directly freeing the allocated memory. Once kobject_init_and_add() has been called, unwind later failures by removing any successfully created sysfs groups, calling kobject_del(), and then releasing the embedded kobject with kobject_put(). Fixes: c1e7e466120b ("IB/mlx4: Add iov directory in sysfs under the ib device") Link: https://patch.msgid.link/r/20260518021910.972900-1-lgs201920130244@gmail.com Signed-off-by: Guangshuo Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3525987a392536f31a484833af258971af63b24c Author: Zhu Yanjun Date: Fri May 15 02:25:37 2026 +0200 RDMA/rxe: Fix a use-after-free problem in rxe_mmap [ Upstream commit 35744ab3d03c5fca8c1752f53fc8fc674e14c561 ] rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_call+0x1c14/0x2790 do_syscall_64+0xd2/0x1050 ? rcu_core+0x352/0x7d0 ? rcu_core_si+0xe/0x20 ? handle_softirqs+0x1aa/0x650 ? __sanitizer_cov_trace_cmp4+0x16/0x30 ? fpregs_assert_state_consistent+0xe1/0x160 ? irqentry_exit+0xb1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e Link: https://patch.msgid.link/r/20260515002537.6209-1-yanjun.zhu@linux.dev Reported-and-tested-by: nasm Suggested-by: nasm Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit abd27a977b419d584efa659488c22d2306987b29 Author: Jacob Moroni Date: Tue May 12 18:38:52 2026 +0000 RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs [ Upstream commit 5ebb3ed757be3e04cf803026004aa0beaeb13e9b ] The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://patch.msgid.link/r/20260512183852.614045-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 335fafb690c655ee81c62b45a7b0ec98c38f42bd Author: Chancel Liu Date: Thu May 7 10:36:52 2026 +0900 ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts [ Upstream commit 8468c8aafe8b5807e5acba2f8aa96d0b3ce0c248 ] Currently dapm_find_widget() manually constructs a prefixed widget name based on the provided DAPM context and compares it using strcmp(). This happens to work in most cases because callers usually know which DAPM context the target widget belongs to and pass in the matching DAPM context. However, this assumption breaks when search_other_contexts is enabled. In such cases, callers may intentionally pass a different DAPM context, while searching for a widget that actually belongs to another DAPM context. For example, when searching for a "DAC" widget, the widget belongs to the codec DAPM and be registered with a codec prefix, while the caller passes card->dapm and intends to search across all DAPM contexts. The current implementation incorrectly applies the caller card DAPM causing the lookup to fail even though the widget exists on the card. Improve the matching strategy to support both use cases: 1. When the caller provides a fully qualified name with prefix, perform exact string matching. This preserves the ability to use prefixes for disambiguation. 2. When the caller provides a bare widget name without prefix, try exact matching first, then fall back to prefix-stripped comparison using snd_soc_dapm_widget_name_cmp(). To determine whether the pin name includes a prefix, a new helper function snd_soc_dapm_pin_has_prefix() is introduced. It checks if the pin name starts with any known component prefix on the card. This fixes widget lookup failures when searching across different DAPM contexts while maintaining backward compatibility for explicitly prefixed lookups. Fixes: ae4fc532244b ("ASoC: dapm: use component prefix when checking widget names") Signed-off-by: Chancel Liu Assisted-by: Cody:Claude-4.5-Sonnet Link: https://patch.msgid.link/20260507013654.2945915-2-chancel.liu@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3b53f0eda26e442ff97016ad4a0724db8fd3781 Author: Han Gao Date: Wed May 20 00:40:07 2026 +0800 pinctrl: spacemit: fix NULL check in spacemit_pin_set_config [ Upstream commit 09c816e5c4d3a8d6d6e4b7537433e5e98505d934 ] spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin. Fixes: a83c29e1d145 ("pinctrl: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Han Gao Reviewed-by: Troy Mitchell Reviewed-by: Yixun Lan Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c49533d4f9950628731f740e721b820e1733762b Author: Samuel Holland Date: Sun Mar 1 17:49:39 2026 +0300 bus: sunxi-rsb: Always check register address validity [ Upstream commit 61192938a5870ac36edae81e4775b680dcf02c61 ] The register address was already validated for read operations in regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations have the same set of possible addresses, and the address is being truncated from u32 to u8 here as well, so the same check is needed. Signed-off-by: Samuel Holland Signed-off-by: Andrey Skvortsov Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Reviewed-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260301144939.1832806-1-andrej.skvortzov@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 059f9953b9270e9223d8b0bd9cab07b646714ce7 Author: Daniel Palmer Date: Fri May 22 18:07:26 2026 +0900 tools/nolibc: stackprotector: Avoid stalling program startup if crng is not init yet [ Upstream commit b882d807fa443b529ae8bf917d7b640a8d555437 ] We are using the getrandom syscall to get a random seed for the stack protector canary but we are calling it with no flags which means it'll block until there is some real randomness to return. This means that if the crng is not ready yet program startup will block and if you are unlucky that could be for a long time and look like the program has crashed. Even if the call to getrandom does not yield any random data, we will still initialize the canary. Fixes: 7188d4637e95 ("tools/nolibc: add support for stack protector") Signed-off-by: Daniel Palmer Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260522090726.726985-1-daniel@thingy.jp Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit c3549f8c833d154af9f12661a4dcd581df5a8c63 Author: Shiraz Saleem Date: Tue May 12 02:40:56 2026 -0700 RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed [ Upstream commit d28654518c8db5d06d27bd3211c0e9a70c18f7c2 ] Replace hardcoded IB_WIDTH_4X/IB_SPEED_EDR with ib_get_eth_speed() to report the actual link speed in mana_ib_query_port(). Fixes: 4bda1d5332ec ("RDMA/mana_ib: Implement port parameters") Link: https://patch.msgid.link/r/20260512094056.264827-1-kotaranov@linux.microsoft.com Signed-off-by: Shiraz Saleem Signed-off-by: Konstantin Taranov Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0d7beef36455275855965cdf37818140d88e4491 Author: Ronaldo Nunez Date: Fri May 22 16:13:48 2026 -0300 pwm: imx27: Fix variable truncation in .apply() [ Upstream commit dc9e08fdbcc3eb08a1d2b868b535081c44425e27 ] Fix a variable truncation when calculating period in microseconds as part of the solution for the ERR051198 in .apply() callback. Example scenario: - Period of 3us (PWMPR = 196 and prescaler = 1) - Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1) - Actual value is 431504384 (truncation to u32) Signed-off-by: Ronaldo Nunez Reviewed-by: Frank Li Link: https://patch.msgid.link/20260522191348.6227-1-rnunez@baylibre.com Fixes: a25351e4c774 ("pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle") Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 7f0c81b8839128bd20b832ab5b97642c88cb9764 Author: Lifeng Zheng Date: Fri May 22 09:49:10 2026 +0530 cpufreq: conservative: Simplify frequency limit handling [ Upstream commit 3494dff89779b73a6c70481c982e0e96d336454a ] cs_dbs_update() performs explicit checks against policy->min/max before updating the target frequency. These checks are redundant as __cpufreq_driver_target() already clamps the requested frequency to the valid policy limits. Remove the unnecessary boundary checks and simplify the update logic. This also fixes an issue introduced by commit 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates"), where stale target comparisons could cause frequency updates to be skipped entirely after deferred adjustments. Closes: https://lore.kernel.org/all/20260421123545.1745998-1-zhenglifeng1@huawei.com/ Fixes: 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates") Signed-off-by: Lifeng Zheng Co-developed-by: Viresh Kumar Signed-off-by: Viresh Kumar Reviewed-by: Zhongqiu Han Link: https://patch.msgid.link/292e6d937890f135e30ec0d2107eaad47cb9a976.1779423281.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6cb9796036814a7321dde93a29d81c6cf1200207 Author: Pengjie Zhang Date: Mon May 18 21:34:57 2026 +0800 cpufreq: Documentation: fix sampling_down_factor range [ Upstream commit 85524e651d20944399322d46fb97960337831d43 ] The ondemand governor implementation accepts sampling_down_factor values from 1 to 100000 via MAX_SAMPLING_DOWN_FACTOR, but the documentation in admin-guide/pm/cpufreq.rst still says the valid range is 1 to 100. Update the documentation to match the actual code. Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation") Reviewed-by: Zhongqiu Han Signed-off-by: Pengjie Zhang Link: https://patch.msgid.link/20260518133457.2408463-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a5fc66d9899c19a7d4b3e86b9483c874381c945d Author: Dmitry Baryshkov Date: Thu May 7 16:02:57 2026 +0300 drm/msm/mdss: correct UBWC programming sequences [ Upstream commit 78de481c75c34623f450abf0f4604344f9396593 ] The UBWC registers in the MDSS region are not dependent on the UBWC version (it is an invalid assumption we inherited from the vendor SDE driver). Instead they are dependent only on the MDSS core revision. Rework UBWC programming to follow MDSS revision and to use required (aka encoder) UBWC version instead of the ubwc_dec_version. Fixes: d68db6069a8e ("drm/msm/mdss: convert UBWC setup to use match data") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/723384/ Link: https://lore.kernel.org/r/20260507-ubwc-rework-v4-1-c19593d20c1d@oss.qualcomm.com Signed-off-by: Sasha Levin commit e88dd4d9c7b348549fffcde226f9aca45d894144 Author: Cássio Gabriel Date: Thu May 14 10:52:35 2026 -0300 ASoC: mediatek: mt8189: Fix probe resource cleanup [ Upstream commit 5404599c3292a12dfc6a3b604cebb5d51064f553 ] The MT8189 AFE probe assigns reserved memory with of_reserved_mem_device_init(), but only releases that assignment from .remove(). If probe fails after the reserved memory has been assigned, the assignment record is left behind. The probe path also uses pm_runtime_get_sync() without checking its return value. If runtime resume fails, pm_runtime_get_sync() leaves the usage count incremented and the driver continues initialization without the device being resumed. Use pm_runtime_resume_and_get() so resume errors abort probe without leaking a PM usage count. Finally, component registration failure currently jumps to a label that drops a runtime PM reference even though the temporary probe reference was already released. Return the component registration error directly, and do not drop an unmatched PM reference from .remove(). Fixes: 7eb153585598 ("ASoC: mediatek: mt8189: add platform driver") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260514-asoc-mt8189-probe-cleanup-v1-1-ded733363281@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fccbae82cb294484597edb179e262d8b6cf11f4f Author: Aleksander Jan Bajkowski Date: Sat May 16 14:26:51 2026 +0200 crypto: eip93 - fix reset ring register definition [ Upstream commit 09e6b79b8ce388993aec9ac91b1cb2c181c27bd9 ] This patch fixes a descriptor ring reset. This causes a hang in the driver's unload/load sequence. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Suggested-by: Benjamin Larsson Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit baea6404c0e96319ea28c6959dc2c387a5356bd6 Author: Saravana Kannan Date: Mon May 11 17:57:49 2026 +0200 of: dynamic: Fix overlayed devices not probing because of fw_devlink [ Upstream commit 81e7c6befa36cecdcbf7244393bd67e8f8c59bf5 ] When an overlay is applied, if the target device has already probed successfully and bound to a device, then some of the fw_devlink logic that ran when the device was probed needs to be rerun. This allows newly created dangling consumers of the overlayed device tree nodes to be moved to become consumers of the target device. [Herve: Add the call to driver_deferred_probe_trigger()] [Herve: Use fwnode_test_flag() to test fwnode flags value] Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays") Reported-by: Herve Codina Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/ Closes: https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/ Closes: https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/ Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/lkml/20240411235623.1260061-3-saravanak@google.com/ [Herve: Rebase on top of recent kernel] Signed-off-by: Herve Codina Tested-by: Kalle Niemi Tested-by: Geert Uytterhoeven Acked-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260511155755.34428-3-herve.codina@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc8041e16efdd2990c908e611c16b251ea65ce2e Author: Saravana Kannan Date: Mon May 11 17:57:48 2026 +0200 Revert "treewide: Fix probing of devices in DT overlays" [ Upstream commit aaf08c52df9a19148731d4a3cfd85d98455db901 ] This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924. While the commit fixed fw_devlink overlay handling for one case, it broke it for another case. So revert it and redo the fix in a separate patch. Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays") Reported-by: Herve Codina Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/ Closes: https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/ Closes: https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/ Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/lkml/20240411235623.1260061-2-saravanak@google.com/ [Herve: Fix conflicts due to f72e77c33e4b ("device property: Make modifications of fwnode "flags" thread safe")] Signed-off-by: Herve Codina Acked-by: Mark Brown Acked-by: Rob Herring (Arm) Acked-by: Wolfram Sang # for I2C Link: https://patch.msgid.link/20260511155755.34428-2-herve.codina@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce052e4fa3bfe08e365ab627c6c8ab866c9ae44c Author: Zhang Yuwei Date: Fri Apr 10 10:44:48 2026 +0800 driver core: Use mod_delayed_work to prevent lost deferred probe work [ Upstream commit 1137838865bfc9a7cd5869c1dc5c22aa45ec12c8 ] The deferred_probe_timeout_work may be permanently and unexpectedly canceled when deferred_probe_extend_timeout() executes concurrently. Starting with deferred_probe_timeout_work pending, the problem can occur after the following sequence: CPU0 CPU1 deferred_probe_extend_timeout -> cancel_delayed_work() => true deferred_probe_extend_timeout -> cancel_delayed_work() -> __cancel_work() -> try_grab_pending() -> schedule_delayed_work() -> queue_delayed_work_on() (Since the pending bit is grabbed, it just returns without queuing) -> set_work_pool_and_clear_pending() (This __cancel_work() returns false and the work will never be queued again) The root cause is that the WORK_STRUCT_PENDING_BIT of the work_struct is set temporarily in __cancel_work() (via try_grab_pending()). This transient state prevents the work_struct from being successfully queued by another CPU. To fix this, replace the original non-atomic cancel and schedule mechanism with mod_delayed_work(). This ensures the modification is handled atomically and guarantees that the work is not lost. Fixes: 2b28a1a84a0e ("driver core: Extend deferred probe timeout on driver registration") Signed-off-by: Zhang Yuwei Link: https://patch.msgid.link/20260410024448.387231-1-zhangyuwei20@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f3d760cab86c7b2274d86f5aa5e32175b20bc583 Author: Stepan Ionichev Date: Thu May 14 22:14:55 2026 +0500 device property: fix fwnode reference leak in fwnode_graph_get_endpoint_by_id() [ Upstream commit 9582485a65eacfd7245ec7f0a9d7e2c34749d669 ] When called with FWNODE_GRAPH_ENDPOINT_NEXT, the function walks every endpoint under the requested port and, for any endpoint whose ID is greater than or equal to the requested one, may store a fwnode reference in best_ep via fwnode_handle_get(). If a later iteration finds an exact-ID match, the function returns that endpoint directly without dropping the reference held by best_ep, leaking it. Drop the saved candidate before returning the exact-match endpoint. This affects callers that use FWNODE_GRAPH_ENDPOINT_NEXT to ask for the next endpoint with ID >= the requested one (used by a number of media drivers, e.g. imx7/8, sun6i CSI, omap3isp, xilinx-csi2, stm32-csi). Each leak retains a fwnode reference until reboot/unbind. Fixes: 0fcc2bdc8aff ("device property: Add fwnode_graph_get_endpoint_by_id()") Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260514171455.27271-1-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0dcc7fec47da3a4cb9589cfa492e5a02a19d43fa Author: Conor Kotwasinski Date: Thu Apr 16 09:43:15 2026 -0400 kernfs: fix suspicious RCU usage in kernfs_put() [ Upstream commit 0fdde3f2aeadcf8d090ee3edee0aad73fb91f690 ] Commit 741c10b096bc ("kernfs: Use RCU to access kernfs_node::name.") converted the WARN_ONCE() in kernfs_put() to read kn->name and parent->name via rcu_dereference(), but kernfs_put() has callers that hold neither kernfs_rwsem nor the RCU read lock. The inode eviction path driven by memory reclaim is one such case: kernfs_put+0x53/0x60 fs/kernfs/dir.c:602 evict+0x3c2/0xad0 fs/inode.c:846 iput_final fs/inode.c:1966 [inline] iput.part.0+0x605/0xf50 fs/inode.c:2015 iput+0x35/0x40 fs/inode.c:1981 dentry_unlink_inode+0x2a1/0x490 fs/dcache.c:467 __dentry_kill+0x1d0/0x600 fs/dcache.c:670 shrink_dentry_list+0x180/0x5e0 fs/dcache.c:1174 prune_dcache_sb+0xea/0x150 fs/dcache.c:1256 super_cache_scan+0x328/0x550 fs/super.c:223 ... kswapd+0x556/0xba0 mm/vmscan.c:7343 lockdep complains with "suspicious RCU usage" whenever the WARN fires from such a context. Wrap the rcu_dereference() calls in an RCU read-side critical section. Gate on the active-ref check so the lock is only taken when the WARN is about to fire. Note that this does not address the underlying imbalance in kn->active that triggers the WARN. Fixes: 741c10b096bc ("kernfs: Use RCU to access kernfs_node::name.") Reported-by: syzbot+0dfe499ea713e0a15bec@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0dfe499ea713e0a15bec Signed-off-by: Conor Kotwasinski Acked-by: Tejun Heo Link: https://patch.msgid.link/20260416134315.1474726-1-conorkotwasinski2024@u.northwestern.edu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d60a8ec640b318b916d71fe3f2f78fba3a827e23 Author: Baokun Li Date: Thu May 21 17:50:15 2026 +0800 writeback: drop now-unnecessary rcu_barrier() in cgroup_writeback_umount() [ Upstream commit e90a6d668e26e00a72df2d09c173b563468f09c9 ] Commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes") replaced the queue_rcu_work() based scheduling of inode wb switches with a plain queue_work(). Since then no switcher goes through call_rcu(), so rcu_barrier() in cgroup_writeback_umount() has no callbacks of its own to wait for. It still drains unrelated call_rcu() callbacks from other subsystems on busy systems, which incidentally slows umount down; drop it. Fixes: e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes") Reviewed-by: Jan Kara Signed-off-by: Baokun Li Link: https://patch.msgid.link/20260521095016.2791354-3-libaokun@linux.alibaba.com Acked-by: Tejun Heo Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 4b23284c347dbe19104ac879c7fd89b213d13401 Author: Joel Selvaraj Date: Wed Apr 29 15:16:53 2026 +0200 arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path [ Upstream commit f3cd85f60c5eb2d817af6c62465018dd941ce4f3 ] The path was accidentally reverted back to old while refactoring of the device-tree. Fixes: 5bde31dc7b17 ("arm64: dts: qcom: sdm845-xiaomi-beryllium: Add placeholders and sort") Signed-off-by: Joel Selvaraj Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260429-beryllium-ipa-fix-v1-1-816326ba9047@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2dbb61fd473bcce82ec0aea4dbe07760e862b361 Author: Gopikrishna Garmidi Date: Mon May 18 02:52:53 2026 -0700 arm64: dts: qcom: glymur: Fix wrong interrupt number for i2c19 [ Upstream commit ecabfe832b817bd1c1fdb8841d7bc706bf621ef1 ] The i2c19 node at 0x88c000 uses GIC SPI 584, but that interrupt belongs to the neighboring i2c18/spi18 node at 0x888000. The correct interrupt for i2c19 is GIC SPI 585, as used by its sibling nodes spi19 and uart19 which share the same register base and clock. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Gopikrishna Garmidi Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260518-glymur-fix-i2c19-irq-v1-1-7d5968bd9b2b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6ead900324537b52e09a7f1d3bfa5e82574d2c8e Author: Ritesh Kumar Date: Wed Jan 28 17:18:50 2026 +0530 arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs [ Upstream commit 4bd073e00fd79c0aead74ad64ade48c904221245 ] The eDP PHY nodes on lemans were missing the reference clock voting. This initially went unnoticed because the clock was implicitly enabled by the UFS PHY driver, and the eDP PHY happened to rely on that. After commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off calls"), the UFS driver no longer keeps the reference clock enabled. As a result, the eDP PHY fails to power on. To fix this, add eDP reference clock for eDP PHYs on lemans chipset ensuring reference clock is enabled. Fixes: e1e3e5673f8d7 ("arm64: dts: qcom: sa8775p: add DisplayPort device nodes") Signed-off-by: Ritesh Kumar Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260128114853.2543416-3-quic_riteshk@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cf334620036ad2250e008c7e7bb6646a3938b7b0 Author: Pengpeng Hou Date: Thu Apr 30 12:33:50 2026 +0800 tracing: Bound synthetic-field strings with seq_buf [ Upstream commit f07883450eb14d1cf020b55d9f3a7ec5683bcd26 ] The synthetic field helpers build a prefixed synthetic variable name and a generated hist command in fixed MAX_FILTER_STR_VAL buffers. The current code appends those strings with raw strcat(), so long key lists, field names, or saved filters can run past the end of the staging buffers. Build both strings with seq_buf and propagate -E2BIG if either the synthetic variable name or the generated command exceeds MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while using the helper intended for bounded command construction. Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260430043350.57928-1-pengpeng@iscas.ac.cn Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Acked-by: Masami Hiramatsu (Google) Reviewed-by: Tom Zanussi Signed-off-by: Pengpeng Hou [ sdr: Moved struct seq_buf *s for upside-down x-mas tree formatting ] Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit dbbb33fe49fac0a88f0cc83ad0114339a21b4ebe Author: Harshal Dev Date: Thu Apr 16 17:29:28 2026 +0530 arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node [ Upstream commit 081ac792f0ea6d27a4b130c70cfd7544efee8137 ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8750. Fixes: b1dac789c650a ("arm64: dts: qcom: sm8750: Add ICE nodes") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-11-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dd0004304a6261ff2d43bce2c420582924ea6427 Author: Harshal Dev Date: Thu Apr 16 17:29:27 2026 +0530 arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node [ Upstream commit c62b084d5d1564f808408a2f7d4c514e57cd4106 ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the UFS_PHY_GDSC power domain is enabled. Specify both the UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8650. Fixes: 10e0246712951 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-10-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e873e3cad2a96a2e8fc915c6fa2b3153440dae46 Author: Harshal Dev Date: Thu Apr 16 17:29:26 2026 +0530 arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node [ Upstream commit 52696dbbe7bbe0c8fc8c17133ffb5133b8cf37a6 ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the UFS_PHY_GDSC power domain is enabled. Specify both the UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8550. Fixes: b8630c48b43fc ("arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-9-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 38ef0ab2a49e498ec555945bd0a1beb89039fee3 Author: Harshal Dev Date: Thu Apr 16 17:29:25 2026 +0530 arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node [ Upstream commit 3a5cb1ccbfb3141862b28f24cd5050083233aae7 ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the UFS_PHY_GDSC power domain is enabled. Specify both the UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8450. Fixes: 86b0aef435851 ("arm64: dts: qcom: sm8450: Use standalone ICE node for UFS") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-8-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit abfa2bad440e2eeab1ba189daf1dffc98d66d72a Author: Harshal Dev Date: Thu Apr 16 17:29:24 2026 +0530 arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node [ Upstream commit cca53c338ad87edc4b46d2d82730fd8ca01a164f ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for kodiak. Fixes: dfd5ee7b34bb7 ("arm64: dts: qcom: sc7280: Add inline crypto engine") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Tested-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-7-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3f93ebf4cba256763b133c71cadc8044e1dde160 Author: Harshal Dev Date: Thu Apr 16 17:29:23 2026 +0530 arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node [ Upstream commit 7cd7271ac525e4eadd22734f418219f247638f43 ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the UFS_PHY_GDSC power domain is enabled. Specify both the UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sc7180. Fixes: 858536d9dc946 ("arm64: dts: qcom: sc7180: Add UFS nodes") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-6-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0f3146ce9a6df80c101c34e3071950a8a1d8030f Author: Harshal Dev Date: Thu Apr 16 17:29:22 2026 +0530 arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node [ Upstream commit 68d5d9701a7ab1b1f9c76feaa3a24ca716f03f0b ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for monaco. Fixes: cc9d29aad876d ("arm64: dts: qcom: qcs8300: enable the inline crypto engine") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-5-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6b3443bf37a86cdf0c59789e862ab6ebe1d10e26 Author: Harshal Dev Date: Thu Apr 16 17:29:21 2026 +0530 arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node [ Upstream commit 04566e287b35fde9fd129db5fdf6a96e336af55c ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the UFS_PHY_GDSC power domain is enabled. Specify both the UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for lemans. Fixes: 96272ba7103d4 ("arm64: dts: qcom: sa8775p: enable the inline crypto engine") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-4-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2f0854496cd652efb638604fdaa68f0470f8ef36 Author: Harshal Dev Date: Thu Apr 16 17:29:20 2026 +0530 arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node [ Upstream commit 11b48f6d5ed505ced9cd3645d6615279198a7a54 ] Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for kaanapali. Fixes: 2eeb5767d53f4 ("arm64: dts: qcom: Introduce Kaanapali SoC") Reviewed-by: Konrad Dybcio Reviewed-by: Kuldeep Singh Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-3-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 37d4d0f75a385ae1d5aa1ba2b02c15e47a774a14 Author: Abel Vesa Date: Fri May 15 16:22:38 2026 +0300 arm64: dts: qcom: eliza-mtp: Fix the debug UART index [ Upstream commit 179d11c1c0cfaddcfc984edc3c1863ab600f679f ] The Eliza MTP debug UART is QUPv3 WRAP2 SE5. The existing DTS labels it as uart14, but the serial-engine index for this block is actually 13. Rename the SoC UART label and pinctrl state to uart13 and update the MTP alias and node reference accordingly. Fixes: af20af39fc09 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi") Fixes: 2a5d4fc6f3f7 ("arm64: dts: qcom: eliza: Enable Eliza MTP board support") Reviewed-by: Konrad Dybcio Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260515-eliza-dts-fix-debug-uart-and-more-support-v2-1-5ad3da81b9d3@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 11bb771f3c55b4cef3879e69da4ddecd6085569c Author: Geert Uytterhoeven Date: Fri May 15 11:59:15 2026 +0200 firmware: arm_scmi: Fix OOB in scmi_power_name_get() [ Upstream commit f9ef3f66f4b18078e464b7606f9497e4dbeb9905 ] scmi_power_name_get() does not validate the domain number passed by the external caller, which may lead to an out-of-bounds access. Fix this by returning "unknown" for invalid domains, like scmi_reset_name_get() does. Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol") Signed-off-by: Geert Uytterhoeven Reviewed-by: Cristian Marussi Link: https://patch.msgid.link/75caae28bdffb55199a0bc6cac5df112a966c608.1778838987.git.geert+renesas@glider.be Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit c27c778c44107e3869e8c20e022b37fa0750c5e7 Author: Sven Püschel Date: Thu May 21 00:44:11 2026 +0200 media: rockchip: rga: fix too small buffer size [ Upstream commit 65017e26c065d1240b0512c15867ef1128034fd8 ] Fix the command buffer size being only a quarter of the actual size. The RGA_CMDBUF_SIZE macro was potentially intended to specify the length of the cmdbuf u32 array pointer. But as it's used to specify the size of the allocation, which is counted in bytes. Therefore adjust the macro size to bytes as it better matches the variable name and adjust it's users accordingly. As the command buffer is relatively small, it probably didn't caused an issue due to being smaller than a single page. Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support") Reviewed-by: Nicolas Dufresne Signed-off-by: Sven Püschel Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1ccb75113f766dac52c444528ea04dc7b611a0de Author: Nishanth Sampath Kumar Date: Wed May 20 08:11:09 2026 -0700 regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16 [ Upstream commit 34808ac8ddafc3e2c2a59e84eaab0a410e7a0fdc ] i2c_smbus_write_word_data() expects a plain u16, but cpu_to_le16() returns __le16 (a sparse-restricted endian type), causing: drivers/base/regmap/regmap-i2c.c:340: sparse: incorrect type in argument 3 (different base types) expected unsigned short [usertype] value got restricted __le16 [usertype] SMBus already defines byte ordering internally, so cpu_to_le16() is wrong here. Replace it with a plain (u16) cast. Fixes: bad4bd28abf4 ("regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605161621.mY5zFh4D-lkp@intel.com/ Signed-off-by: Nishanth Sampath Kumar Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 32064f2dfe6db8f69d5bd655332cb427dc451e30 Author: Eric Dumazet Date: Tue May 19 09:46:17 2026 +0000 net/sched: sch_drr: annotate data-races around cl->deficit [ Upstream commit c67b104fd7982162885c5e43057ca761006748e2 ] drr_dump_class_stats() runs without qdisc spinlock held. Add missing READ_ONCE()/WRITE_ONCE() annotations around cl->deficit. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260519094618.2632073-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e143d5b150af2b030c8df201f3c14c68902337df Author: GuoHan Zhao Date: Mon Apr 27 09:21:28 2026 +0800 vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done [ Upstream commit b9285405c5f6144f4444f97bf3048d865e11cc1d ] xe_vfio_pci_reset_done() sets deferred_reset and, when it manages to acquire state_mutex itself, hands the cleanup off to xe_vfio_pci_state_mutex_unlock(). That helper already clears deferred_reset and runs xe_vfio_pci_reset() before dropping the mutex. Calling xe_vfio_pci_reset() again right afterwards repeats the reset handling unnecessarily. Fixes: 1f5556ec8b9e ("vfio/xe: Add device specific vfio_pci driver variant for Intel graphics") Signed-off-by: GuoHan Zhao Reviewed-by: Kevin Tian Acked-by: Michał Winiarski Link: https://lore.kernel.org/r/20260427012128.117051-1-zhaoguohan@kylinos.cn Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 29cb06dabcd6e03e3d2104429d5d9de1eacead40 Author: Hongling Zeng Date: Wed May 20 19:15:47 2026 +0900 nilfs2: Fix return in nilfs_mkdir [ Upstream commit e5925f33e4fa9ee313d481557607adce8e30ed2e ] Return NULL instead of passing zero to ERR_PTR. Fixes smatch warning: - fs/nilfs2/namei.c:261 nilfs_mkdir() warn: passing zero to 'ERR_PTR' Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 1203f9ea8fd4a343f9e27b5be9d1d2075b244fc5 Author: David Matlack Date: Tue Apr 28 23:27:06 2026 +0000 vfio: selftests: Allow builds when ARCH=x86 [ Upstream commit 75182529687e204b2bd046a3f7b1c2acb5031032 ] Allow builds when ARCH=x86 since the top-level Makefile can set ARCH=x86 even for 64-bit x86 builds. Note that ARCH=x86 could also indicate a native build on a 32-bit x86 host. However, it doesn't seem like anyone is building selftests natively on 32-bit x86 hosts these days since KVM selftests allow ARCH=x86 and fail to compile on 32-bit x86. If someone reports an issue on 32-bit native builds we can harden the KVM and VFIO selftests to explicitly check 64-bit (see the discussion in the Closes link below). Fixes: a55d4bbbe644 ("vfio: selftests: only build tests on arm64 and x86_64") Reported-by: Jason Gunthorpe Closes: https://lore.kernel.org/kvm/20260427231217.GA1670652@nvidia.com/ Signed-off-by: David Matlack Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20260428232707.2139059-1-dmatlack@google.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 8d33d107c1308ac02c4e0e1331852cb951667516 Author: Jason Gunthorpe Date: Thu May 14 13:04:44 2026 -0300 vfio: selftests: Fix out-of-tree build with make O= [ Upstream commit a21b864bd951e452922dbd66747da24daca2b04f ] The test programs are compiled via a static pattern rule that requires intermediate .o files: $(TEST_GEN_PROGS): %: %.o $(LIBVFIO_O) After lib.mk prefixes TEST_GEN_PROGS with $(OUTPUT), this creates dependencies on .o files in the output directory (e.g. $(OUTPUT)/vfio_dma_mapping_test.o). However, there is no rule to compile these .o files from the source directory .c files when OUTPUT differs from the source directory. Add an explicit chain of pattern rules: $(OUTPUT)/% -> $(OUTPUT)/%.o -> %.c Following the same pattern already used in libvfio.mk for the library objects. Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests") Reviewed-by: David Matlack Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/0-v2-4ccc247e6aff+1d93-vfio_st_make_o_jgg@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 0451ddd2cf16452a30adb512dfea00d57d970202 Author: Daniel Palmer Date: Wed May 20 20:19:31 2026 +0900 tools/nolibc: getopt: Fix potential out of bounds access [ Upstream commit 136ca91411b0b637e862eb7b1cce2a56853edd17 ] Running clang-tidy on a program that uses getopt() from nolibc this warning appears: getopt.h:80:6: warning: Out of bound access to memory after the end of the string literal [clang-analyzer-security.ArrayBound] 80 | if (optstring[i] == ':') { This looks like a very unlikely case that an argument inside of argv is being changed between getopt() calls. Adding a check for d becoming 0 in the guard after the loop stops getopt() getting far enough to access beyond the end of the array and seems to correct the issue. Fixes: bae3cd708e8a ("tools/nolibc: add getopt()") Assisted-by: Claude:claude-4.6-sonnet # reproducer Signed-off-by: Daniel Palmer Link: https://patch.msgid.link/20260520111931.1027758-1-daniel@thingy.jp [Thomas: clean up commit message a bit] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit b22cebba03efb16c13ecdb3b76bb43ed3503de0a Author: Chen-Yu Tsai Date: Thu May 14 17:15:15 2026 +0800 regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions [ Upstream commit cdc517688ffa2c30a64a20b558a9ecbf046c70f1 ] The name of the regulator should match what the board design specifies for the power rail. There should be no limitations on what the name can be, and they definitely don't always follow the PMIC's own names. Drop the restrictions on regulator-name. Fixes: 8771456635d5 ("dt-bindings: regulator: Add document for MT6359 regulator") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260514091520.2718987-3-wenst@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6003b1a0bc343b18fb097b54ba83100f433ed959 Author: Randy Dunlap Date: Sat May 2 22:25:08 2026 -0700 bitops: use common function parameter names [ Upstream commit 8a51b2e874f47a6094353b59ecae421f0968fe3a ] Fix the function prototypes to use the common parameter name 'addr' instead of 'p' (common to arch-specific implementations of these functions). This avoids the kernel-doc warnings: Warning: include/asm-generic/bitops/lock.h:19 function parameter 'p' not described in 'arch_test_and_set_bit_lock' Warning: include/asm-generic/bitops/lock.h:41 function parameter 'p' not described in 'arch_clear_bit_unlock' Warning: include/asm-generic/bitops/lock.h:59 function parameter 'p' not described in 'arch___clear_bit_unlock' Fixes: 84c6591103db ("locking/atomics, asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*()") Signed-off-by: Randy Dunlap Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit ba7f353f3a152b174dde99f8c1518a3e54a61388 Author: Greg Kroah-Hartman Date: Wed May 20 15:07:01 2026 +0200 sysfs: clamp show() return value in sysfs_kf_read() [ Upstream commit 454257f6d124a92342dcbb7710c03dd6ef96c731 ] sysfs_kf_seq_show() defends against buggy show() callbacks that return larger than PAGE_SIZE by clamping the value and printing a warning. sysfs_kf_read(), the prealloc variant, has no such defense. The only current in-tree user of __ATTR_PREALLOC is drivers/md/md.c, whose show() callbacks are well-behaved, so this is hardening against future drivers doing foolish things and out-of-tree code doing even more foolish things. Cc: NeilBrown Cc: Tejun Heo Fixes: 2b75869bba67 ("sysfs/kernfs: allow attributes to request write buffer be pre-allocated.") Assisted-by: gregkh_clanker_t1000 Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/2026052000-drove-unicycle-d61b@gregkh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9730135f28dee325e32f80a7cdf00c5659ead5b2 Author: Guoniu Zhou Date: Tue May 19 10:07:38 2026 +0800 media: synopsys: Fix IPI using hardcoded datatype [ Upstream commit 8ba166ff7c921da610376156d7c0a5fc985fa983 ] The imx93_csi2rx_dphy_ipi_enable() function configures the IPI datatype using csi2->formats->csi_dt, which is initialized during probe but never updated in set_fmt(). This causes the IPI to always use the probe-time default datatype, ignoring the actual media bus format negotiated at runtime. When userspace requests a different format, the IPI hardware is configured with the wrong datatype, resulting in incorrect image output. Fix by updating csi2->formats in the set_fmt callback to reflect the currently negotiated format, ensuring the IPI configuration matches the runtime datatype. Fixes: ec40b431f0ab ("media: synopsys: csi2rx: add i.MX93 support") Reviewed-by: Frank Li Signed-off-by: Guoniu Zhou Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 923bf9f5b7fbf4f0b2403b05c74e00671f90fb82 Author: Sudeep Holla Date: Sun May 17 20:02:40 2026 +0100 firmware: arm_scmi: Read sensor config as 32-bit value [ Upstream commit f6fe7c3c007df18afd289ff2d98c692fae9ab085 ] The SENSOR_CONFIG_GET response contains a 32-bit sensor_config field, and the xfer is initialized with a 4-byte RX buffer. Reading it with get_unaligned_le64() can consume bytes past the returned payload. Use get_unaligned_le32() to match the protocol layout and the allocated response size. Fixes: 7b83c5f41088 ("firmware: arm_scmi: Add SCMI v3.0 sensor configuration support") Link: https://patch.msgid.link/20260517-scmi_fixes-v1-1-d86daec4defd@kernel.org Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 5d0b8fcea617ef5be3fe44574551e1f8d996fc85 Author: Andre Przywara Date: Tue Sep 2 18:20:53 2025 +0100 firmware: smccc: Fix Arm SMCCC SOC_ID name call [ Upstream commit 70492cfce2a4d41e87bf46989028a90f4bc6b38f ] Commit 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID name") introduced the SOC_ID name string call, which reports a human readable string describing the SoC, as returned by firmware. The SMCCC spec v1.6 describes this feature as AArch64 only, since we rely on 8 characters to be transmitted per register. Consequently the SMCCC call must use the AArch64 calling convention, which requires bit 30 of the FID to be set. The spec is a bit confusing here, since it mentions that in the parameter description ("2: SoC name (optionally implemented for SMC64 calls, ..."), but still prints the FID explicitly as 0x80000002. But as this FID is using the SMC32 calling convention (correct for the other two calls), it will not match what any SMCCC conformant firmware is expecting, so any call would return NOT_SUPPORTED. Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that for the SoC name version of the call to fix the issue. Fixes: 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID name") Signed-off-by: Andre Przywara Link: https://patch.msgid.link/20250902172053.304911-1-andre.przywara@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 9a454b0a5017c306e7793d0a51ec05386ef32aba Author: Aurelien Jarno Date: Tue May 19 06:12:39 2026 +0200 riscv: dts: spacemit: fix uboot partition offset on Milk-V Jupiter [ Upstream commit 6edd9a0d32e1ef81133b8cb5b3bb3157a44da4d1 ] Correct the uboot partition node name to match its actual offset. Fixes: 2829823956f0 ("riscv: dts: spacemit: enable QSPI and add SPI NOR on Milk-V Jupiter") Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260519041458.3287843-6-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 311efbb24eddce7a0ff291f377d2b6974baf6e6f Author: Aurelien Jarno Date: Tue May 19 06:12:35 2026 +0200 riscv: dts: spacemit: set console baud rate on Milk-V Jupiter [ Upstream commit 4f97acb4f744f516bbe976da8282c0fe213216ff ] Because the default console's baud rate is not set, defconfig kernels do not have any serial output on this platform. Set the baud rate to 115200, matching what is used by U-Boot etc on this platform. See-also: 24c12ca43b12c ("dts: spacemit: set console baud rate on bpif3") Fixes: 5b90a3d6092d9 ("riscv: dts: spacemit: Add Milk-V Jupiter board device tree") Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260519041458.3287843-2-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 3040b1d34a1f888a694a9d4ffa4b5779ef8d109b Author: Jose A. Perez de Azpillaga Date: Thu Mar 26 22:34:07 2026 +0100 staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy() [ Upstream commit 9087395a383212ab1beaefcbe3b57ed131c7823d ] The nested loop inside the IS_ISP2401 block incorrectly uses the same variable 'i' as the outer loop. This shadows the outer loop variable and causes premature termination or skipped array elements. Change the inner loop to use a new variable 'j' to prevent this. Fixes: 113401c67386 ("media: atomisp: sh_css: Removed #ifdef ISP2401 to make code generic") Signed-off-by: Jose A. Perez de Azpillaga Reviewed-by: Dan Carpenter Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit f614bf0a64aa1cb7444d152a96798a6bf1d49e1f Author: Yuho Choi Date: Thu Apr 2 20:23:19 2026 -0400 media: atomisp: gc2235: fix UAF and memory leak [ Upstream commit 628f763aee0047ff44974388d6f70f75a763026b ] gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Yuho Choi Reviewed-by: Dan Carpenter Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit c2fb3a440ac78abbe72ba6decbc4b20ac9a8405e Author: Zilin Guan Date: Tue Feb 3 16:31:34 2026 +0000 media: atomisp: Fix memory leak in atomisp_fixed_pattern_table() [ Upstream commit 4e8156bd9517fa18c3613ea39c222c7035f0221e ] atomisp_v4l2_framebuffer_to_css_frame() allocates memory for temporary variable raw_black_frame, which must be released via ia_css_frame_free() before the function returns. However, if sh_css_set_black_frame() fails, the function returns immediately without performing this cleanup, leading to a memory leak. Fix this by assigning the return value of sh_css_set_black_frame() to ret. This ensures that the error code is propagated while allowing the execution to fall through to the ia_css_frame_free() cleanup call. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We performed build testing on x86_64 with allyesconfig. Since triggering this error path in atomisp requires specific Intel Atom ISP hardware and firmware, we were unable to perform runtime testing and instead verified the fix according to the code logic. Fixes: 85b606e02ad7 ("media: atomisp: get rid of a bunch of other wrappers") Signed-off-by: Zilin Guan Reviewed-by: Andy Shevchenko Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit ba608e9b5a4e9b6b0ee6be880d733cbafad2a07b Author: Viacheslav Dubeyko Date: Thu May 14 12:55:19 2026 -0700 hfs: fix incorrect inode ID assignment in hfs_new_inode() [ Upstream commit 6592287869bffee91f59363e51de5f971ec2bd9d ] The xfstests' test-case generic/003 reveals the HFS volume corruption: sudo ./check generic/003 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #18 SMP PREEMPT_DYNAMIC Fri Mar 13 17:54:19 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/003 51s ... _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent sudo fsck.hfs -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. invalid MDB drNxtCNID Master Directory Block needs minor repair (1, 0) Verify Status: VIStat = 0x8000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The reason of corruption is incorrect value of drNxtCNID (next CNID) in the MDB or superblock. The generic/003 test-case creates several new inodes: kernel: run fstests generic/003 hfs: hfs_mdb_get():179 next_id 16 hfs: hfs_mdb_get():179 next_id 16 hfs: hfs_new_inode():208 next_id 17 hfs: hfs_new_inode():208 next_id 18 hfs: hfs_mdb_commit():307 next_id 18 hfs: hfs_mdb_get():179 next_id 18 hfs: hfs_new_inode():208 next_id 19 hfs: hfs_new_inode():208 next_id 20 hfs_mdb_commit():307 next_id 20 hfs: hfs_mdb_get():179 next_id 20 hfs: hfs_new_inode():208 next_id 21 hfs: hfs_mdb_commit():307 next_id 21 hfs: hfs_mdb_get():179 next_id 21 The final assigned CNID was 21 but fsck correct it on 22. It is possible to see that the reason of the issue is incrementing the next_id value at first and assigning already incremented value to the inode->i_ino: struct inode *hfs_new_inode(...) { next_id = atomic64_inc_return(&HFS_SB(sb)->next_id); inode->i_ino = (u32)next_id; } This patch fixes the issue by assigning the decremented value to inode->i_ino. Fixes: a06ec283e125 ("hfs: add logic of correcting a next unused CNID") cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260514195518.354108-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit ba5fc6b6448a3b740c6684fb8b7cd571eaff6b86 Author: Sherry Sun Date: Sat May 9 09:54:11 2026 +0800 arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply [ Upstream commit 596d0f9f4fefffbf783ab26cfa90cf50f5dd6bb0 ] The vpcie-supply property should reference the regulator that controls the actual M.2 power supply, not the W_DISABLE1# signal. On imx95-19x19-evk: - reg_pcie0 controls M.2 W_DISABLE1# signal - reg_m2_pwr controls the actual M.2 power supply Fix the vpcie-supply to use reg_m2_pwr for proper power control in PCIe endpoint mode. Fixes: 58bea81052d0 ("arm64: dts: imx95: add pcie1 ep overlay file and create pcie-ep dtb files") Signed-off-by: Sherry Sun Reviewed-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 1b8584e7df354bf3003c38027684cb35130d9b26 Author: Sherry Sun Date: Sat May 9 09:54:10 2026 +0800 arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply [ Upstream commit b5ba136d535f1060322af31c0cf74d85ea19892d ] For PCIe endpoint mode, only M.2 power supply needs to be ensured. On imx8qxp-mek, the M.2 power is always on and cannot be controlled, while reg_pcieb only controls the M.2 W_DISABLE1# signal. Remove the unnecessary vpcie-supply property from pcie0_ep node. Fixes: 1c9b0c6044c2 ("arm64: dts: imx8: use common imx-pcie0-ep.dtso to enable PCI ep function") Signed-off-by: Sherry Sun Reviewed-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6623515c4eee4bc5e4769aefab7205e1e2b7fc7a Author: Sherry Sun Date: Sat May 9 09:54:09 2026 +0800 arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties [ Upstream commit 538525f34158deb21b782164bde23ec07a353e4a ] For PCIe endpoint mode, only M.2 power supply needs to be ensured. On imx8dxl-evk, the M.2 power is always on and cannot be controlled, while reg_pcieb only controls the M.2 W_DISABLE1# signal. Remove the unnecessary vpcie-supply property from pcie0_ep node. Also remove reset-gpio as PCIe endpoint mode doesn't require reset control. Fixes: c1c4820b60d7 ("arm64: dts: imx8dxl-evk: Add pcie0-ep node and use unified pcie0 label") Signed-off-by: Sherry Sun Reviewed-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit e618f5d1028989a568b66d06b33de986638cdbc1 Author: Francesco Dolcini Date: Thu Apr 9 11:33:04 2026 +0200 arm64: dts: freescale: imx95-verdin-ivy: fix RS485 RTS polarity [ Upstream commit 9f004f2afded2870838c0ae4906c2fa9307286bb ] Fix the RS485 functionality, the RS485 RTS signal is active high on Ivy. Fixes: f33a1f9a942c ("arm64: dts: freescale: imx95-verdin: Add Ivy carrier board") Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 0a81d683e78d1b0d4856212338df0b5df3719650 Author: Jamie Nguyen Date: Mon May 18 13:31:16 2026 -0700 firmware: arm_ffa: Honor partition info descriptor size [ Upstream commit 01b9cae706161a39452a2cce0f281d4369344c51 ] FFA_PARTITION_INFO_GET_REGS reports the size of each partition information descriptor in x2[63:48]. However, __ffa_partition_info_get_regs() walks the returned register payload with a hardcoded 24-byte stride (regs += 3), even though the size is already read into buf_sz. That works for the FF-A v1.1/v1.2 24-byte descriptor layout, where each descriptor consumes three registers. Newer FF-A revisions can extend the descriptor while keeping the existing fields at the front. For example, a 48-byte descriptor consumes six registers, so advancing by only three registers desynchronises the parser and can make it read subsequent entries from the middle of a descriptor. Use the advertised descriptor size to derive the register stride. Validate that the size is register-aligned, large enough for the fields parsed by the driver, and that the requested number of descriptors fits in the returned x3..x17 register window. The driver still copies only the fields it understands, but now skips over any trailing descriptor fields correctly. Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Suggested-by: Sudeep Holla Signed-off-by: Jamie Nguyen Link: https://patch.msgid.link/20260518203116.42624-1-jamien@nvidia.com (sudeep.holla: Minor rewordng of the commit message and subject) Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 4235d57b36c3d6adc9b4c3e8ad2404d6711853d0 Author: Kevin Brodsky Date: Mon Apr 27 13:03:34 2026 +0100 selftests/mm: Fix resv_sz when parsing arm64 signal frame [ Upstream commit c364aa56d6738c8759e88941d7a45a1d6b4c52d0 ] get_header() wants the size of the reserved area in struct sigcontext, but instead we pass it the size of the entire struct. This could in theory result in an out-of-bounds read (if the signal frame is malformed). Fix this using one of the existing macros from tools/testing/selftests/arm64/signal/testcases/testcases.h. This issue was reported by Sashiko on a patch that copied this portion of the code. Link: https://sashiko.dev/#/patchset/20260421144252.1440365-1-kevin.brodsky%40arm.com Fixes: f5b5ea51f78f ("selftests: mm: make protection_keys test work on arm64") Signed-off-by: Kevin Brodsky Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit cc12d55ea9d8d5a5c479010fe7518554e4842f4c Author: Vincent Guittot Date: Mon May 18 12:23:45 2026 +0200 sched/fair: Update util_est after updating util_avg during dequeue [ Upstream commit 6d2051403d6c93832d3058a1b275c6aef2c97f44 ] util_est_update() must be called after updating util_avg during the dequeue of a task and only when the task is not delayed dequeue. Move util_est_update() in update_load_avg(). Fixes: b55945c500c5 ("sched: Fix pick_next_task_fair() vs try_to_wake_up() race") Closes: https://lore.kernel.org/all/20260512124653.305275-1-qyousef@layalina.io/ Reported-by: Qais Yousef Reviewed-and-tested-by: Qais Yousef Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260518102345.268452-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit 60e37bc8809915234239c96d9836ec602c817af8 Author: Bibek Kumar Patro Date: Thu Apr 23 15:32:30 2026 +0530 iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table [ Upstream commit a6e1618a65d453d4e739e5898c662ccb1e3de6c0 ] The qcom_smmu_actlr_client_of_match table contained "qcom,fastrpc" as the compatible string for applying ACTLR prefetch settings to FastRPC devices. However, "qcom,fastrpc" is the compatible string for the parent rpmsg channel node, which is not an IOMMU client — it carries no "iommus" property in the device tree and is never attached to an SMMU context bank. The actual IOMMU clients are the compute context bank (CB) child nodes, which use the compatible string "qcom,fastrpc-compute-cb". These nodes carry the "iommus" property and are probed by fastrpc_cb_driver via fastrpc_cb_probe(), which sets up the DMA mask and IOMMU mappings for each FastRPC session. The device tree structure is: fastrpc { compatible = "qcom,fastrpc"; /* rpmsg channel, no iommus */ ... compute-cb@3 { compatible = "qcom,fastrpc-compute-cb"; iommus = <&apps_smmu 0x1823 0x0>; /* actual IOMMU client */ }; }; Since qcom_smmu_set_actlr_dev() calls of_match_device() against the device being attached to the SMMU context bank, the "qcom,fastrpc" entry was never matching any device. As a result, the ACTLR prefetch settings (PREFETCH_DEEP | CPRE | CMTLB) were silently never applied for FastRPC compute context banks. Fix this by replacing "qcom,fastrpc" with "qcom,fastrpc-compute-cb" in the match table so that the ACTLR settings are correctly applied to the compute CB devices that are the true IOMMU clients. Assisted-by: Claude:claude-sonnet-4-6 Fixes: 3e35c3e725de ("iommu/arm-smmu: Add ACTLR data and support for qcom_smmu_500") Reviewed-by: Dmitry Baryshkov Reviewed-by: Shawn Guo Signed-off-by: Bibek Kumar Patro Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3204e6b35e8c389493648d3ceaa0c68fd399bfee Author: Paul Chaignon Date: Mon May 18 18:26:35 2026 +0200 selftests/bpf: Fix test for refinement of single-value tnum [ Upstream commit 523d2f42b406f5be2989f436b03eacebf3679835 ] This patch fixes the "bounds refinement with single-value tnum on umin" verifier selftest. This selftest was introduced in commit e6ad477d1bf8 ("selftests/bpf: Test refinement of single-value tnum") to cover the logic from __update_reg64_bounds(), introduced in commit efc11a667878 ("bpf: Improve bounds when tnum has a single possible value"). However, the test still passes if that last commit is reverted. The test is supposed to cover the case when the tnum and u64 range (or cnum64 now) overlap in a single value. __update_reg64_bounds() detects that case and refines the bounds to a known constant. However, the constants for the test were poorly chosen and the bounds get refined to a known constant even without __update_reg64_bounds(). The code is as follows: 0: call bpf_get_prandom_u32#7 ; R0=scalar() 1: r0 |= 224 ; R0=scalar(umin=umin32=224,var_off=(0xe0; 0xffffffffffffff1f)) 2: r0 &= 240 ; R0=scalar(smin=umin=smin32=umin32=224,smax=umax=smax32=umax32=240,var_off=(0xe0; 0x10)) 3: if r0 == 0xf0 goto pc+2 ; R0=224 After instruction 3, we have u64=[0xe0; 0xef] and tnum=(0xe0; 0x10). __reg_bound_offset() is able to deduce a new tnum from the u64, tnum=(0xe0; 0x0f), which combined with the existing tnum gives us a constant: 0xe0 or 224. We can easily fix this by choosing different starting bounds. If we make it u64=[0xe1; 0xf0], then __reg_bound_offset() doesn't have any impact. Fixes: e6ad477d1bf8 ("selftests/bpf: Test refinement of single-value tnum") Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/be2dc2c3d85120286e60b3029b3338fff339f942.1779121582.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4aa01da6cf93d1a6a034e74a6eda0893d4496984 Author: Roman Kvasnytskyi Date: Sat May 16 14:06:25 2026 +0200 selftests/bpf: Reject unsupported -k option in vmtest.sh [ Upstream commit 6df582112aa9ac9d190169abdb0e42e496659ec9 ] vmtest.sh does not document a -k option and does not handle it in the getopts case statement. However, the getopts optstring includes k, which causes the script to accept -k silently instead of reporting it as an invalid option. Remove k from the optstring so unsupported options are rejected through the existing invalid-option path. Fixes: c9709f52386d ("bpf: Helper script for running BPF presubmit tests") Signed-off-by: Roman Kvasnytskyi Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260516120625.80839-1-roman@kvasnytskyi.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 659a61123cbe264fbf657e9240448d2cfa2df8c5 Author: Paul Chaignon Date: Wed May 13 13:24:37 2026 +0200 selftests/bpf: Override EXTRA_LDFLAGS for static builds [ Upstream commit 879daba303f7d7c3057f4d218921621e751f1912 ] When running vmtest.sh with static linking, the bpftool_map_access selftests fail. These selftests are calling the bpftool binary in tools/sbin/ directly, which results in the following error: error while loading shared libraries: libLLVM.so.21.1: cannot open shared object file: No such file or directory To fix this, we need to also build bpftool statically. That can be done by setting EXTRA_LDFLAGS=-static. Fixes: 2d96bbdfd3b5 ("selftests/bpf: convert test_bpftool_map_access.sh into test_progs framework") Signed-off-by: Paul Chaignon Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/r/714556da329c812988010ffe53173d9152570a78.1778669303.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6c4ede3b771adbb3bf21ad4e8b8f2f6f6120c4f7 Author: Fengnan Chang Date: Wed May 13 17:13:49 2026 +0800 dm: limit target bio polling to one shot [ Upstream commit 5aa0f9231cbacade065cedd8e9b5ebd067231171 ] dm_poll_bio() is the ->poll_bio() callback for a stacked dm device. The caller only knows about the dm queue, so it may decide to do a spinning poll if it thinks a single queue is being polled. Passing those flags unchanged to the mapped clone lets blk_mq_poll() spin on a target queue from inside dm_poll_bio(). With io_uring IOPOLL on a dm-stripe target this can keep a task in dm_poll_bio() -> bio_poll() -> blk_mq_poll() long enough to trigger an RCU CPU stall, before io_uring gets back to io_iopoll_check() and its need_resched() check. Keep dm's ->poll_bio() bounded by forcing one-shot polling for target bios. The caller can invoke dm_poll_bio() again if it wants to keep polling, and it also gets a chance to reap completions or reschedule between passes. Fixes: f22ecf9c14c1 ("blk-mq: delete task running check in blk_hctx_poll()") Signed-off-by: Fengnan Chang Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 5c5994a1204743fa55e4c198ed93a6c36f21cd1f Author: Liviu Dudau Date: Thu May 7 11:50:46 2026 +0100 drm/syncobj: Fix memory leak in drm_syncobj_find_fence() [ Upstream commit e5b93bd6fdb92aa5e4689715d7e8487d9ce66a38 ] Commit 18226ba52159 ("drm/syncobj: reject invalid flags in drm_syncobj_find_fence") forgot to take into account the fact that drm_syncobj_find() takes a reference to syncobj and returns early without dropping the reference, leading to memory leaks. Fixes: 18226ba52159 ("drm/syncobj: reject invalid flags in drm_syncobj_find_fence") Reported by: Sam Spencer Signed-off-by: Liviu Dudau Acked-by: Erik Kurzinger Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/all/20260507144425.2488057-1-liviu.dudau@arm.com Signed-off-by: Sasha Levin commit 9b75c38776a00189c243f762e0da6b6f83854f03 Author: Crystal Wood Date: Tue May 12 12:37:31 2026 -0500 rtla: Stop the record trace on interrupt [ Upstream commit f03a59f949176ce4312cb466245d1243aaf40389 ] Before, when rtla got a signal, it stopped the main trace but not the record trace. With "--on-end trace", this can lead to save_trace_to_file() failing to keep up, especially on a debug kernel. Plus, it adds post-stoppage noise to the trace file. Signed-off-by: Crystal Wood Fixes: c73cab9dbed0 ("rtla/timerlat_hist: Stop timerlat tracer on signal") Fixes: a4dfce7559d7 ("rtla/timerlat_top: Stop timerlat tracer on signal") Fixes: 3aadb65db5d6 ("rtla/timerlat: Add action on end feature") Link: https://lore.kernel.org/r/20260512173731.2151841-1-crwood@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit e3c2b81d6761bf2e49911838abe76daf354db7a1 Author: Costa Shulyupin Date: Tue Apr 14 21:52:18 2026 +0300 tools/rtla: Fix --dump-tasks usage in timerlat [ Upstream commit 704fe8f3d97bba842f5f357e317116f1b88169e8 ] Fix --dump-task to --dump-tasks in timerlat_hist usage string and getopt_long table for consistency with timerlat_top. Add missing --dump-tasks to timerlat_top usage synopsis. Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Costa Shulyupin Fixes: 2091336b9a8b ("rtla/timerlat_hist: Add auto-analysis support") Link: https://lore.kernel.org/r/20260414185223.65353-1-costa.shul@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 06e195936fca7c40893cdbd2ba0cac17e1966acb Author: Junxian Huang Date: Thu May 7 09:21:46 2026 +0800 RDMA/hns: Initialize seqfile before creating file [ Upstream commit b4070770506ff516e21b4923afdaf7eb5da0e150 ] The debugfs file was created before seq->read and seq->data were set, leaving a small window where userspace could access an uninitialized seqfile. Move debugfs_create_file() after the assignments to avoid this issue. Also, inline the original init_debugfs_seqfile() since it is not a really necessary helper. Fixes: ca7ad04cd5d2 ("RDMA/hns: Add debugfs to hns RoCE") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260507012148.1079712-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 72497172a4799119a0282a5eb5e2b8ddcc821921 Author: Sara Venkatesh Date: Mon May 4 01:00:36 2026 -0700 RDMA/srpt: fix integer overflow in immediate data length check [ Upstream commit eb4ecdf631fe00e8020bf461503cb9b7017ed796 ] imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison. Fixes: 5dabcd0456d7 ("RDMA/srpt: Add support for immediate data") Reported-by: Carlos Bilbao (Lambda) Signed-off-by: Sara Venkatesh Link: https://patch.msgid.link/20260504080036.3482415-1-sarajvenkatesh@gmail.com Reviewed-by: Carlos Bilbao (Lambda) Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 78b9589fda266c71f0f9d0c858d4fa7381a890a5 Author: Prathamesh Deshpande Date: Tue Apr 28 23:42:49 2026 +0100 RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference [ Upstream commit 43f8f7946814c8e5f464518246fdbc69b6e32326 ] MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up. Fixes: 759738537142 ("IB/mlx5: Enable subscription for device events over DEVX") Signed-off-by: Prathamesh Deshpande Link: https://patch.msgid.link/20260428224319.37682-1-prathameshdeshpande7@gmail.com Reviewed-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9619909d4869afe720904c6888a289b9ac3055b8 Author: Prathamesh Deshpande Date: Sun Apr 26 14:23:41 2026 +0100 RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure [ Upstream commit 1eae35b37923cb71b0cb5136d00671440d488b9f ] mlx5r_umr_update_xlt() allocates and DMA maps an XLT buffer with mlx5r_umr_create_xlt(). The buffer is released by the common cleanup path through mlx5r_umr_unmap_free_xlt(). After mlx5_odp_populate_xlt() became fallible, its error path returned directly and skipped that cleanup. This leaks the XLT DMA mapping and buffer. If the emergency XLT page was used, it also leaves xlt_emergency_page_mutex locked. Break out of the loop so execution falls through the existing cleanup path. Fixes: 1efe8c0670d6 ("RDMA/core: Convert UMEM ODP DMA mapping to caching IOVA and page linkage") Signed-off-by: Prathamesh Deshpande Link: https://patch.msgid.link/20260426132356.22264-1-prathameshdeshpande7@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8efee40ef632d94fe141474bbde2c327e7791a08 Author: Alexander Chesnokov Date: Mon Apr 13 12:14:43 2026 +0300 RDMA/hns: Fix arithmetic overflow in calc_hem_config() [ Upstream commit a38e4410af9ad8b7ad2217254da06cd4dc21f0ed ] If bt_num is 3 or 2, then the expressions like l0_idx * chunk_ba_num + l1_idx are computed in 32-bit arithmetic before being assigned to a u64 index field, which can lead to overflow. Cast the first operand to u64 to ensure the arithmetic is performed in 64-bit. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2f49de21f3e9 ("RDMA/hns: Optimize mhop get flow for multi-hop addressing") Signed-off-by: Alexander Chesnokov Link: https://patch.msgid.link/20260413091527.39990-1-Alexander.Chesnokov@kaspersky.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f88e12c95fc19f719e06ca1e9eb20fdad68ef61a Author: Prathamesh Deshpande Date: Sun Apr 12 02:18:49 2026 +0100 IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier [ Upstream commit e79389115b9d27287ff6230a9750675106ed7668 ] mlx5_ib_alloc_transport_domain() allocates a transport domain and then may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked. Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init(). Fixes: 146d2f1af324 ("IB/mlx5: Allocate a Transport Domain for each ucontext") Signed-off-by: Prathamesh Deshpande Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e889aa99ad3ed48bb0ddcff6475b17542532d18b Author: Linmao Li Date: Wed May 13 10:55:09 2026 +0800 ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD [ Upstream commit 627ac78f2741e2ebd2225e2e953b6964a8a9182f ] addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released. Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue") Signed-off-by: Linmao Li Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260513025509.3776405-1-lilinmao@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5bf2f3a739b948223fa4a2529087865afeb3a9da Author: Eric Dumazet Date: Thu May 14 09:59:33 2026 +0000 net/sched: sch_htb: annotate data-races (I) [ Upstream commit e54c33503bf7cebb1c1790251ce90f1252678081 ] htb_dump() runs without holding qdisc spinlock. Add missing READ_ONCE()/WRITE_ONCE() annotations around q->overlimits and q->direct_pkts. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260514095935.3926276-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbd521a10c60749a81b6036eb869fb2e35076a15 Author: Eric Dumazet Date: Thu May 14 09:59:32 2026 +0000 net/sched: sch_htb: do not change sch->flags in htb_dump() [ Upstream commit 9b949fa69129e4b694ed11ee3be6d6edd4a9b8f4 ] htb_dump() runs without holding qdisc spinlock. It is illegal to touch sch->flags with non locked RMW, as concurrent readers might see intermediate wrong values. Set TCQ_F_OFFLOADED in control path (htb_init()) instead. Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260514095935.3926276-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1e94b098328a7eb95b9b14fa8307a7f6cf7e4d4 Author: Eric Dumazet Date: Thu May 14 11:47:13 2026 +0000 net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats() [ Upstream commit 5658bddaca41417331d2ac4b24a9b159a839ab87 ] dualpi2_dump_stats() runs without qdisc lock held. Add missing READ_ONCE()/WRITE_ONCE() annotations. Fixes: d4de8bffbef4 ("sched: Dump configuration and statistics of dualpi2 qdisc") Signed-off-by: Eric Dumazet Cc: Vineet Agarwal Link: https://patch.msgid.link/20260514114713.4134674-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b53e561dd96595deb175d52afb6be9a3c58a6efa Author: Eric Dumazet Date: Sun May 10 09:14:49 2026 +0000 net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec() [ Upstream commit 863cd78652018576c60f1b73477a15bdb0ea7551 ] Helpers to increment or decrement sch->q.qlen, with appropriate WRITE_ONCE() to prevent store tearing. Add other WRITE_ONCE() when sch->q.qlen is changed. Signed-off-by: Eric Dumazet Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260510091455.4039245-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5658bddaca41 ("net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()") Signed-off-by: Sasha Levin commit 160b64b41559b18a4a4c37042bfb313cdfaa4d40 Author: Qiang Ma Date: Fri May 15 18:26:20 2026 +0800 spi: hisi-kunpeng: Use dev_err_probe() for host registration failure [ Upstream commit 59b991990a04b1d1ce95373983b7c8b65bdf7acc ] When the SPI core registers the Kunpeng controller it may need to acquire chip-select GPIO descriptors. If the GPIO provider has not probed yet, spi_register_controller() returns -EPROBE_DEFER. On a Kunpeng system this currently prints an alarming error even though the next deferred-probe retry succeeds: hisi-kunpeng-spi HISI03E1:00: failed to register spi host, ret=-517 hisi-kunpeng-spi HISI03E1:00: hw version:0x30 max-freq:12500 kHz Use dev_err_probe() so that -EPROBE_DEFER is reported through the deferred probe mechanism instead of as a hard error, while preserving normal error reporting for real registration failures. Fixes: c770d8631e18 ("spi: Add HiSilicon SPI Controller Driver for Kunpeng SoCs") Signed-off-by: Qiang Ma Link: https://patch.msgid.link/20260515102620.1926930-1-maqianga@uniontech.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2de04bc78f63bcf1f4487fb99c3640eacda3d7e8 Author: Abdun Nihaal Date: Fri May 8 14:33:45 2026 +0530 crypto: safexcel - Fix potential memory leak in safexcel_pci_probe() [ Upstream commit c36faca103a685590281412e47df74b550f71886 ] The memory allocated for priv in safexcel_pci_probe() is not freed in the error paths, as well as in the PCI remove function. Fix this by using device managed allocation. Fixes: 625f269a5a7a ("crypto: inside-secure - add support for PCI based FPGA development board") Signed-off-by: Abdun Nihaal Reviewed-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6bafd740095fb3d0e9a00540bc8f3484c38e6f85 Author: Stepan Ionichev Date: Thu May 7 19:06:08 2026 +0500 crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL [ Upstream commit 930d9d36ea618a775985446a125aedeb401db522 ] dsm_create() initially checks pdev->bus when computing segment_id: u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0; But the next two lines unconditionally dereference pdev->bus via pcie_find_root_port() and especially pci_dev_id(pdev), which expands to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact NULL, segment_id is initialised to 0 but the very next statement crashes the kernel. smatch flags this: drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we previously assumed 'pdev->bus' could be null (see line 251) Make the NULL handling consistent: if pdev->bus is NULL the device has no PCI context to work with and SEV TIO setup cannot proceed, so return -ENODEV before any of the bus-dependent lookups. The remaining initialisation now runs only on the path where pdev->bus is known to be valid. No change for callers where pdev->bus is non-NULL, which is the only case where dsm_create() did meaningful work before this change. Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)") Signed-off-by: Stepan Ionichev Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0b3a57d218618cb1cc78ddc9ba02c07de84b46f4 Author: Herbert Xu Date: Tue May 5 17:02:45 2026 +0800 crypto: af_alg - Cap AEAD AD length to 0x80000000 [ Upstream commit e4c06479d7059888adf2f22bc1ebcf053bf691a2 ] In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000. Reported-by: Yiming Qian Fixes: 400c40cf78da ("crypto: algif - add AEAD support") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d88071a6ce091272726bedda26c105b85b23705f Author: Sean Christopherson Date: Mon May 4 15:28:12 2026 -0700 crypto: ccp - Treat zero-length cert chain as query for blob lengths [ Upstream commit ef8c9dacda2871accd64e3eda951fef6b788b1ea ] When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: [] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [] vfs_ioctl fs/ioctl.c:52 [inline] [] __do_sys_ioctl fs/ioctl.c:598 [inline] [] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0). Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4867dba229292e13fc19ed865ec1839661952ff9 Author: Yihang Li Date: Sat Apr 25 16:20:56 2026 +0800 scsi: hisi_sas: Add slave_destroy interface for v3 hw [ Upstream commit 67b85a88265df19f049241d8c00571a5408f4eeb ] WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log: WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0 Call trace: __device_links_no_driver+0xb4/0xc0 device_links_driver_cleanup+0xb0/0xfc __device_release_driver+0x198/0x23c device_release_driver+0x38/0x50 bus_remove_device+0x130/0x140 device_del+0x184/0x434 __scsi_remove_device+0x118/0x150 scsi_remove_target+0x1bc/0x240 sas_rphy_remove+0x90/0x94 sas_rphy_delete+0x24/0x3c sas_destruct_devices+0x64/0xa0 [libsas] sas_revalidate_domain+0xe4/0x150 [libsas] process_one_work+0x1e0/0x46c worker_thread+0x15c/0x464 kthread+0x160/0x170 ret_from_fork+0x10/0x20 ---[ end trace 71e059eb58f85d4a ]--- During SAS phy up, link->status is set to DL_STATE_AVAILABLE in device_links_driver_bound, then this setting influences __device_links_no_driver() before driver rmmod and caused WARNING. Add the slave_destroy interface to make sure link is removed after flush workque. Fixes: 16fd4a7c5917 ("scsi: hisi_sas: Add device link between SCSI devices and hisi_hba") Signed-off-by: Yihang Li Link: https://patch.msgid.link/20260425082056.2749910-1-liyihang9@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8a046e68f073b2420337541a194de274d4858eb5 Author: Eric Dumazet Date: Wed May 13 08:08:53 2026 +0000 net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats() [ Upstream commit e300c7d470ad2726d6abf7d11b31b5d9912d9cf0 ] hfsc_dump_class_stats() runs without qdisc spinlock being held. Add READ_ONCE()/WRITE_ONCE() annotations around: - cl->level - cl->cl_vtperiod - cl->cl_total - cl->cl_cumul Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260513080853.1383975-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d85543848ef03e6b1614fa3609c14485bd24b4ff Author: Stepan Ionichev Date: Wed May 13 14:09:00 2026 +0500 clk: scpi: Unregister child clock providers on remove [ Upstream commit b79d9b5747d961516c35ef4d5e91efa579fd3e9a ] SCPI clock providers are registered for each child node in scpi_clk_add(), but scpi_clocks_remove() unregisters the parent node on each iteration. of_clk_del_provider() matches providers by the node used at registration time, so passing the parent node leaves the child providers registered. This leaks the provider allocations and the node references held by the clock provider core. Pass the child node to of_clk_del_provider() so the remove path matches the probe path. Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)") Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260513090900.5323-1-sozdayvek@gmail.com (sudeep.holla: Updated commit title and message a bit) Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 996957016bc1403c6b981dc2a0a26aae241bef71 Author: Rafael J. Wysocki Date: Tue May 5 13:44:01 2026 +0200 thermal: hwmon: Register a hwmon device for each thermal zone [ Upstream commit d6323469bcfbda91f0aa89b7b39ad45fe822ca5d ] The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type. That turns out to be problematic when the thermal zone holding the hwmon device is removed. For example, say that there are two ACPI thermal zones on a system /sys/devices/virtual/thermal/thermal_zone0/ /sys/devices/virtual/thermal/thermal_zone1/ The current code registers a hwmon class device for thermal_zone0 only: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/ because the type is "acpitz" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input There is also /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input which belongs to thermal_zone0. When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, the removal code skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress. To address this problem, rework the thermal hwmon code to register one hwmon device for each thermal zone, but since user space utilities produce confusing output in some cases when there are multiple hwmon devices with the same name attribute value present under thermal zones of the same type, append the thermal zone ID preceded by an underline character to the name of the hwmon device registered for that thermal zone. Link: https://lore.kernel.org/linux-pm/20260402021828.16556-1-liujia6264@gmail.com/ Fixes: f6b6b52ef7a5 ("thermal_hwmon: Pass the originating device down to hwmon_device_register_with_info") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3070412.e9J7NaK4W3@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 403c3703a1054a83694a00239950f6faf96f92e6 Author: Rafael J. Wysocki Date: Tue May 5 13:36:56 2026 +0200 thermal: hwmon: Fix critical temperature attribute removal [ Upstream commit c2114dbda05354dbcf4dfbb30a2c623e8611c43a ] Since the return value of thermal_zone_crit_temp_valid() depends on the behavior of the thermal zone .get_crit_temp() callback which may change over time in theory, thermal_remove_hwmon_sysfs() may attempt to remove a critical temperature attribute that has not been created, passing a pointer to an uninitialized attribute structure to device_remove_file(). To avoid that, set a flag in struct thermal_hwmon_temp after creating a critical temperature attribute and use the value of that flag to decide whether or not the attribute needs to be removed. Fixes: e8db5d6736a7 ("thermal: hwmon: Make the check for critical temp valid consistent") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2437056.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 38b7d63b23aa9d2ddde7688040e9426d32be4065 Author: Pengpeng Hou Date: Thu Apr 23 23:30:00 2026 +0800 evm: terminate and bound the evm_xattrs read buffer [ Upstream commit 11143a19f5b8dc8f414deab87571134f9f447313 ] evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer(). Fixes: fa516b66a1bf ("EVM: Allow runtime modification of the set of verified xattrs") Signed-off-by: Pengpeng Hou Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 817c94be630305ca86127d7361deb1a0a551e96a Author: Lin He Date: Sat May 9 11:23:02 2026 +0800 drm/hisilicon/hibmc: use clock to look up the PLL value [ Upstream commit 99ef3a4f1c1813cabd50bb3e8522e85e00838bb2 ] In the past, we use width and height to look up our PLL value. But actually the actual clock check is also necessnary. There are some resolutions that width and height same, but its clock different. Add the clock check when using pll_table to determine the PLL value. Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Signed-off-by: Lin He Signed-off-by: Yongbang Shi Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260509032302.2057227-5-shiyongbang@huawei.com Signed-off-by: Sasha Levin commit 0fbf47903c8773dc0cb4f0e8c499d17a15135c94 Author: Lin He Date: Sat May 9 11:23:01 2026 +0800 drm/hisilicon/hibmc: move display contrl config to hibmc_probe() [ Upstream commit de2a56c71f9b223922ea8fe0192d3c1fa2954608 ] If there's no VGA output, this encoder modeset won't be called, which will cause displaying data from GPU being cut off. It's actually a common display config for DP and VGA, so move the vdac encoder modeset to driver load stage. Removed invalid bit configurations from `hibmc_display_ctrl` Fixes: 5294967f4ae4 ("drm/hisilicon/hibmc: Add support for VDAC") Signed-off-by: Lin He Signed-off-by: Yongbang Shi Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260509032302.2057227-4-shiyongbang@huawei.com Signed-off-by: Sasha Levin commit 056d3482beb42f94e2a2d712324a1dd3ac06495c Author: Lin He Date: Sat May 9 11:23:00 2026 +0800 drm/hisilicon/hibmc: fix no showing when no connectors connected [ Upstream commit 4110e29a7c384f1ff21d6b187b6a1772f6e17b23 ] Our chip support KVM over IP feature, so hibmc driver need to support displaying without any connectors plugged in. If no connectors are connected, the vdac connector status should be set to 'connected' to ensure proper KVM display functionality. Additionally, for previous-generation products that may lack hardware link support and thus cannot detect the monitor, the same approach should be applied to ensure VGA display functionality. * Add phys_state in the struct of dp and vdac to check physical outputs. * The 'epoch_counter' of the vdac connector is incremented when the physical status changes. For get_modes: using BMC modes for connector if no display is attached to phys VGA cable, otherwise use EDID modes by drm_connector_helper_get_modes, because KVM doesn't provide EDID reads. The polling mechanism for the KMS helper is enabled. Fixes: 4c962bc929f1 ("drm/hisilicon/hibmc: Add vga connector detect functions") Reported-by: Thomas Zimmermann Closes: https://lore.kernel.org/all/0eb5c509-2724-4c57-87ad-74e4270d5a5a@suse.de/ Signed-off-by: Lin He Signed-off-by: Yongbang Shi Reviewed-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260509032302.2057227-3-shiyongbang@huawei.com Signed-off-by: Sasha Levin commit 69c58f39e39aba60fa5de1bdf6251979d5cd701e Author: Lin He Date: Sat May 9 11:22:59 2026 +0800 drm/hisilicon/hibmc: add updating link cap in DP detect() [ Upstream commit 7d380ef98dd469747b6df43fb0243301b0caaacf ] In the past, the link cap is updated in link training at encoder enable stage, but the hibmc_dp_mode_valid() is called before it, which will use DP link's rate and lanes. So add the hibmc_dp_update_caps() in hibmc_dp_update_caps() to avoid some potential risks. Fixes: 607805abfb74 ("drm/hisilicon/hibmc: add dp mode valid check") Signed-off-by: Lin He Signed-off-by: Yongbang Shi Acked-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260509032302.2057227-2-shiyongbang@huawei.com Signed-off-by: Sasha Levin commit bd74bb16c6be1256b323b64f24ffce71110319a0 Author: Rafael J. Wysocki Date: Tue May 12 18:36:42 2026 +0200 platform/chrome: wilco_ec: event: Check ACPI_COMPANION() [ Upstream commit 51dcff9796fd486d7abf01081ca62e4072789e9d ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the wilco_ec event driver. Fixes: 27d58498f690 ("platform/chrome: wilco_ec: event: Convert to a platform driver") Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/2076666.usQuhbGJ8B@rafael.j.wysocki Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit f4061f6d56bc48f268569f3d2b664b45fa913e5e Author: Rafael J. Wysocki Date: Tue May 12 18:35:54 2026 +0200 platform/chrome: chromeos_tbmc: Check ACPI_COMPANION() [ Upstream commit c15dbae7c856fb53cc6ffb86c6c64ebb816d07c8 ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the chromeos_tbmc driver. Fixes: a2676ead257f ("platform/chrome: chromeos_tbmc: Convert to a platform driver") Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/1875121.VLH7GnMWUR@rafael.j.wysocki Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 1c7a943d5b040ddf5dc470580cdb1e9f8712afa5 Author: Rafael J. Wysocki Date: Tue May 12 18:35:20 2026 +0200 platform/chrome: chromeos_privacy_screen: Check ACPI_COMPANION() [ Upstream commit 8a4a217f617b1ac2f8c095f33efd67d947ddb2cf ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the chromeos_privacy_screen driver. Fixes: d3c2872ae323 ("platform/chrome: Convert ChromeOS privacy-screen driver to platform") Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/3357444.5fSG56mABF@rafael.j.wysocki Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 3d7c342e478a38df98041350ccd6bae35746d286 Author: Kuldeep Singh Date: Thu Apr 2 00:05:10 2026 +0530 arm64: dts: qcom: sm8450: Fix ICE reg size [ Upstream commit 7fb3d0512dacc0d09217eb45057357f00298203d ] The ICE register region size was originally described incorrectly when the ICE hardware was first introduced. The same value was later carried over unchanged when the ICE node was split out from the UFS node into its own DT entry. Correct the register size to match the hardware specification. Fixes: 276ee34a40c1 ("arm64: dts: qcom: sm8450: add Inline Crypto Engine registers and clock") Signed-off-by: Kuldeep Singh Reviewed-by: Harshal Dev Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260402-ice_dt_reg_fix-v1-2-74e4c2129238@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bf76824320bf8b536736fc0ddb15537df61134a7 Author: Kuldeep Singh Date: Thu Apr 2 00:05:09 2026 +0530 arm64: dts: qcom: kodiak: Fix ICE reg size [ Upstream commit fa9c7403af64d3e56a6c20dedc60e0a55b527509 ] The ICE register region on Kodiak is currently defined as 0x8000 bytes. According to the hardware specification, the correct register size is 0x18000. Update the ICE node reg property to match the hardware. Fixes: dfd5ee7b34bb ("arm64: dts: qcom: sc7280: Add inline crypto engine") Signed-off-by: Kuldeep Singh Reviewed-by: Harshal Dev Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260402-ice_dt_reg_fix-v1-1-74e4c2129238@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 89abf027fa7c96d238811bc91946247641a95ce5 Author: Krzysztof Kozlowski Date: Tue Mar 31 18:56:46 2026 +0200 arm64: dts: qcom: sm8750: Fix DSI1 phy reference clock rate [ Upstream commit f4d7c5875a215cd3989b59d13a9c30cec9f0a33b ] The DSI PHY CXO clock input is the SoC CXO divided by two. DSI0 already uses correct one, but DSI1 got copy-paste from SM8650. Wrong clock parent will cause incorrect DSI1 PHY PLL frequencies to be used making the DSI panel non-working, although there is no upstream user of DSI1. Fixes: 818ae2b389bc ("arm64: dts: qcom: sm8750: Add display (MDSS) with Display CC") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260331165645.233965-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d937ee3169a95410888d9ac4ee4a204396f242f3 Author: Cristian Marussi Date: Fri May 8 16:32:46 2026 +0100 clk: scmi: Fix clock rate rounding [ Upstream commit d0c81a38d06d446d341532700b3a4a43d3b00eb1 ] While the do_div() helper used for rounding expects its divisor argument to be a 32bits quantity, the currently provided divisor parameter is a 64bit value that, as a consequence, is silently truncated and a possible source of bugs. Fix by using the proper div64_ul helper. Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-clk@vger.kernel.org Fixes: 7a8655e19bdb ("clk: scmi: Fix the rounding of clock rate") Signed-off-by: Cristian Marussi Tested-by: Florian Fainelli Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260508153300.2224715-2-cristian.marussi@arm.com Reviewed-by: Brian Masney Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit a2da42614ca75e276a60922ccbcfa42d61b14547 Author: Hsiu Che Yu Date: Sat Apr 25 18:16:19 2026 +0800 rust: alloc: fix `Vec::extend_with` SAFETY comment [ Upstream commit f497aae6ded43f91b1dbf29a35d7062823635640 ] Fix an incorrect operator in the SAFETY comment, changing `<` to `<=`, since `Vec::reserve` guarantees capacity for exactly n additional elements, so the equal case should be included. Signed-off-by: Hsiu Che Yu Reviewed-by: Alexandre Courbot Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type") Link: https://patch.msgid.link/18fc8eee2f057a6bfbcadae156d1d0b7c40d0077.1777111268.git.yu.whisper.personal@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 35f6814c98b987cd5b1a29b485301e888b37e461 Author: Christian Brauner Date: Mon Apr 27 13:09:57 2026 +0200 rhashtable: give each instance its own lockdep class [ Upstream commit 060d4e94b8d400b62453890821bd7feecd4cde2c ] syzbot reported a possible circular locking dependency between &ht->mutex and fs_reclaim: CPU0 (kswapd0) CPU1 (kworker) -------------- -------------- fs_reclaim ht->mutex shmem_evict_inode rhashtable_rehash_alloc simple_xattrs_free bucket_table_alloc(GFP_KERNEL) rhashtable_free_and_destroy __kvmalloc_node mutex_lock(&ht->mutex) might_alloc -> fs_reclaim The two halves of the splat refer to two different events on &ht->mutex. The kswapd0 path is unambiguous: shmem_evict_inode at mm/shmem.c:1429 calls simple_xattrs_free(), which calls rhashtable_free_and_destroy() on the per-inode simple_xattrs rhashtable being torn down with the inode. The previously-recorded ht->mutex -> fs_reclaim edge comes from rht_deferred_worker -> rhashtable_rehash_alloc -> bucket_table_alloc(GFP_KERNEL) -> __kvmalloc_node -> might_alloc -> fs_reclaim. That stack stops at generic library code: there is no subsystem-specific frame above rht_deferred_worker, so the splat does not identify which rhashtable's worker recorded the edge -- only that some rhashtable in the system did. Whether or not that recording happened on the same simple_xattrs ht that is now being destroyed, the predicted deadlock cannot occur: rhashtable_free_and_destroy() does cancel_work_sync(&ht->run_work) before taking ht->mutex, so the deferred worker cannot be running on the instance being torn down. If the recording was on a different rhashtable instance, the two ht->mutex acquisitions are on distinct mutex objects and cannot deadlock either. Lockdep flags a cycle regardless because mutex_init(&ht->mutex) lives on a single source line in rhashtable_init_noprof(), so every ht->mutex in the kernel shares one static lockdep class. Lockdep matches by class, not by instance, and collapses all of these into one node. Lift the lockdep key out of rhashtable_init_noprof() and into the caller. The user-visible rhashtable_init_noprof() / rhltable_init_noprof() identifiers become macros that declare a per-call-site static lock_class_key. Link: https://patch.msgid.link/20260427-work-rhashtable-lockdep-v1-1-f69e8bd91cb2@kernel.org Fixes: c6307674ed82 ("mm: kvmalloc: add non-blocking support for vmalloc") Acked-by: Michal Hocko Reported-by: syzbot+5af806780f38a5fe691f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/69e798fe.050a0220.24bfd3.0032.GAE@google.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit bbd427f79dd642cc48ffd39ca3f9d4f1cc84e255 Author: Abel Vesa Date: Wed Apr 15 10:52:56 2026 +0300 arm64: dts: qcom: glymur: Mark USB SS1 and SS2 as role-switch capable [ Upstream commit 347fa2fa64e1cef0c7897522896c0c66e734c82b ] Like USB SS0, the USB SS1 and SS2 controllers on Glymur also support USB role switching. Describe this by adding the 'usb-role-switch' property to both controllers. Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes") Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260415-dts-qcom-glymur-usb-role-switch-fix-v1-1-409e1a257f1f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6d2b08731caf6b6c9f77d1992acfa953ddf5492d Author: Abel Vesa Date: Wed Apr 15 10:52:57 2026 +0300 arm64: dts: qcom: glymur-crd: Drop forced host mode for USB SS0 and SS1 [ Upstream commit d9dc254945756b44fa6f61b9cbd4adf0413c6a6f ] The two USB Type-C ports on Glymur CRD are dual-role capable. Do not force their controllers into host mode. Drop the explicit 'dr_mode = "host"' properties so they can use their default OTG mode instead. Fixes: c8b63029455b ("arm64: dts: qcom: glymur-crd: Enable USB support") Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260415-dts-qcom-glymur-usb-role-switch-fix-v1-2-409e1a257f1f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5a4cb517245032d5be55175f82f3d67895e8f5c4 Author: Yang Wang Date: Thu May 7 16:09:51 2026 +0800 drm/amdgpu: fix error return code in mes_v12_1_map_test_bo [ Upstream commit 5da1e1dfd15727918aab2c1a79c019f179991e80 ] The function mes_v12_1_map_test_bo incorrectly returned 0 unconditionallyon error path, which would hide the real error code and mislead upperlayers about the failure status. Fix it by returning the correct error code 'r' instead of 0. Fixes: 44e5195fa3d4 ("drm/amdgpu/mes_v12_1: add mes self test"); Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4f250d54c6efe98e7e19821ce2bf7e58248a2c7f Author: Breno Leitao Date: Mon May 11 05:26:55 2026 -0700 workqueue: forbid TEST_WORKQUEUE from being built-in [ Upstream commit 1503043fd75e29ad49c7d506232e272f6951d07d ] The benchmark drives the workqueue's affinity_scope through sysfs by filp_open()'ing /sys/bus/workqueue/devices/bench_wq/affinity_scope. When CONFIG_TEST_WORKQUEUE=y, the module_init runs during kernel init before userspace has mounted sysfs, so every open returns -ENOENT and the benchmark loop spins emitting: test_workqueue: open /sys/bus/workqueue/devices/bench_wq/affinity_scope failed: -2 Mirror the TEST_BPF pattern and add "depends on m" so Kconfig will not let this be built into the kernel image, and document the reason in the help text. Fixes: 24b2e73f9700 ("workqueue: add test_workqueue benchmark module") Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit ce75126fa35b445c1978eda7db5f15d49058bb78 Author: Chen-Yu Tsai Date: Thu Apr 30 20:07:24 2026 +0800 arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to host [ Upstream commit 533275a4b5240a2bf2c592bd4536560388306d26 ] The DMA bounce buffer is attached to the PCIe host controller, i.e. all PCIe DMA transfers should use it. Move it from the PCIe (WiFi) device node down to the PCIe host controller node. Fixes: 0dca9f0b3e63 ("arm64: dts: mediatek: asurada: Enable PCIe and add WiFi") Signed-off-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 2b6f1de3aa5e1545b99e6b6f17ec7b9894e9d915 Author: Frank Wunderlich Date: Sun Apr 12 11:23:32 2026 +0200 arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling [ Upstream commit e309fa232d12b969afac43a4b7d83dee025cfe63 ] The active-high property in base-dt cannot be overwritten and must be set in separate overlay. Fixes: f397471a6a8c ("arm64: dts: mediatek: mt7988: Add devicetree for BananaPi R4 Pro") Signed-off-by: Frank Wunderlich Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 5f12ed66624b5b769276580afefda721200c6aea Author: Stefan Metzmacher Date: Tue Apr 7 18:03:14 2026 +0200 sockptr: fix usize check in copy_struct_from_sockptr() for user pointers [ Upstream commit db0493512931fe1e5a71612e6a358df1aa22d80c ] copy_struct_from_user will never hit the check_zeroed_user() call and will never return -E2BIG if new userspace passed new bits in a larger structure than the current kernel structure. As far as I can there are no critical/related uapi changes in - include/net/bluetooth/bluetooth.h and net/bluetooth/sco.c after the use of copy_struct_from_sockptr in v6.13-rc3 - include/uapi/linux/tcp.h and net/ipv4/tcp_ao.c after the use of copy_struct_from_sockptr in v6.6-rc1 So that new callers will get the correct behavior from the start. Fixes: 4954f17ddefc ("net/tcp: Introduce TCP_AO setsockopt()s") Fixes: ef84703a911f ("net/tcp: Add TCP-AO getsockopt()s") Fixes: faadfaba5e01 ("net/tcp: Add TCP_AO_REPAIR") Fixes: 3e643e4efa1e ("Bluetooth: Improve setsockopt() handling of malformed user input") Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov Cc: Francesco Ruggeri Cc: Salam Noureddine Cc: David Ahern Cc: David S. Miller Cc: Michal Luczaj Cc: David Wei Cc: Luiz Augusto von Dentz Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Cc: Xin Long Cc: Eric Dumazet Cc: Kuniyuki Iwashima Cc: Paolo Abeni Cc: Willem de Bruijn Cc: Neal Cardwell Cc: Jakub Kicinski Cc: Simon Horman Cc: Aleksa Sarai Cc: Christian Brauner CC: Kees Cook Cc: netdev@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher Link: https://patch.msgid.link/cfaedbc33ae9d36adaabf04fa79424f30ff1efdd.1775576651.git.metze@samba.org Reviewed-by: Aleksa Sarai Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 9ac7c0ae081fceec3ab0982572d3983d2a9b6bfc Author: Stefan Metzmacher Date: Tue Apr 7 18:03:13 2026 +0200 uaccess: fix ignored_trailing logic in copy_struct_to_user() [ Upstream commit 4911de3145a797389577abfdf9a5185d36cc18d7 ] Currently all callers pass ignored_trailing=NULL, but I have code that will make use of. Now it actually behaves like documented: * If @usize < @ksize, then the kernel is trying to pass userspace a newer struct than it supports. Thus we only copy the interoperable portions (@usize) and ignore the rest (but @ignored_trailing is set to %true if any of the trailing (@ksize - @usize) bytes are non-zero). Fixes: 424a55a4a908 ("uaccess: add copy_struct_to_user helper") Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov Cc: Francesco Ruggeri Cc: Salam Noureddine Cc: David Ahern Cc: David S. Miller Cc: Michal Luczaj Cc: David Wei Cc: Luiz Augusto von Dentz Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Cc: Xin Long Cc: Eric Dumazet Cc: Kuniyuki Iwashima Cc: Paolo Abeni Cc: Willem de Bruijn Cc: Neal Cardwell Cc: Jakub Kicinski Cc: Simon Horman Cc: Aleksa Sarai Cc: Christian Brauner CC: Kees Cook Cc: netdev@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher Link: https://patch.msgid.link/71f69442410c1186ed8ce6d5b4b9d4a5a70edbad.1775576651.git.metze@samba.org Reviewed-by: Aleksa Sarai Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 0160edf2af51c5fde742973742c5d10497901b21 Author: Matt Bobrowski Date: Thu Apr 30 07:38:36 2026 +0000 bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries [ Upstream commit 07410646f6ff1d23222f105ccab778957d401bbe ] bpf_set_dentry_xattr and bpf_remove_dentry_xattr BPF kfuncs attempt to lock the inode of the supplied dentry without checking if it is NULL. If a negative dentry is passed (e.g. from security_inode_create), d_inode(dentry) returns NULL, and inode_lock(inode) will cause a NULL pointer dereference. Trivially fix this by adding a NULL check for inode before attempting to lock it, returning -EINVAL if it is NULL. Additionally, drop WARN_ON(!inode) in bpf_xattr_read_permission() and bpf_xattr_write_permission(). These warnings could be triggered by passing a negative dentry to bpf_get_dentry_xattr() or the _locked variants of the xattr kfuncs, potentially causing a Denial of Service on systems with panic_on_warn enabled. Instead, simply return -EINVAL. Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Closes: https://lore.kernel.org/bpf/1587cbf4-1293-4e25-ad24-c970836a1686@std.uestc.edu.cn/ Fixes: 56467292794b ("bpf: fs/xattr: Add BPF kfuncs to set and remove xattrs") Signed-off-by: Matt Bobrowski Link: https://patch.msgid.link/20260430073836.2894001-1-mattbobrowski@google.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 5bd6191d0f8145e5bcca943058278cc3ffeae1b8 Author: Luca Leonardo Scorcia Date: Tue May 5 22:13:16 2026 +0100 soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge [ Upstream commit 7d462de9f65b002b439b1b168bf3b5579b0de48b ] The original patch that was sent to the mailing lists included the values for the route masks, but they got lost during merge: add back the full register masks where missing. Fixes: 060f7875bd23 ("soc: mediatek: mmsys: Add support for MT8167 SoC") Signed-off-by: Luca Leonardo Scorcia Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit d2a2614d487c1b4b2680a1e231fadafca863d349 Author: Sean Christopherson Date: Fri Mar 14 20:21:48 2025 -0700 iommu/amd: Fix a stale comment about which legacy mode is user visible [ Upstream commit 4bf53c2d0c08bbdaa32f2114281f1ddab61902bf ] Update a stale comment about which of the legacy modes is visible to the user, i.e. can be forced via amd_iommu_intr=legacy. Fixes: b74aa02d7a30 ("iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system") Signed-off-by: Sean Christopherson Reviewed-by: Vasant Hegde Reviewed-by: Wei Wang Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 8d855fbb913039b841f7fabadc5fa019deb3f94b Author: Dmitry Baryshkov Date: Mon Feb 9 03:32:18 2026 +0200 media: venus: scale MMCX power domain on SM8250 [ Upstream commit f45fd3dbb5f6d60a8b31d5cc4affaf1ef40163b3 ] On SM8250 most of the video clocks are powered by the MMCX domain, while the PLL is powered on by the MX domain. Extend the driver to support scaling both power domains, while keeping compatibility with the existing DTs, which define only the MX domain. Fixes: 0aeabfa29a9c ("media: venus: core: add sm8250 DT compatible and resource data") Reviewed-by: Bryan O'Donoghue Reviewed-by: Dikshita Agarwal Signed-off-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 92908ee078096d2d9bb44d8395acc011e2cefda6 Author: Dmitry Baryshkov Date: Mon Feb 9 03:32:17 2026 +0200 media: iris: scale MMCX power domain on SM8250 [ Upstream commit 4170e2f25ce40b69f3827fcdabf395380095e136 ] On SM8250 most of the video clocks are powered by the MMCX domain, while the PLL is powered on by the MX domain. Extend the driver to support scaling both power domains, while keeping compatibility with the existing DTs, which define only the MX domain. Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC") Reviewed-by: Dikshita Agarwal Signed-off-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit a71475405397ab04a259da518b2ce505fe794084 Author: Shawn Guo Date: Tue Mar 31 17:01:47 2026 +0800 arm64: dts: qcom: lemans: Move PCIe devices into soc node [ Upstream commit 8222873cd4698627c08bffb2e40ba6f5a008fe32 ] These PCIe devices with MMIO address should be inside soc node rather than outside. Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes") Signed-off-by: Shawn Guo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260331090147.18522-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6df549d0307b4d2cb58d6c478e823ed4f296bdec Author: Nickolay Goppen Date: Wed Apr 29 12:30:10 2026 +0300 arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly [ Upstream commit e8e1fb5c703fc6962103ffdc60830df99351c139 ] Changing FastRPC compute-cbs' reg values to matching iommu streams solves SMMU translation errors when trying to use FastRPC on ADSP so change FastRPC compute-cbs' reg values that way Fixes: af2ce7296643 ("arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Ekansh Gupta Signed-off-by: Nickolay Goppen Link: https://lore.kernel.org/r/20260429-qcom-sdm660-cdsp-adsp-fastrpc-dts-fix-v5-3-16bc82e622ad@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8dcf3edaea35aca276501b2e9f822d94a373c2d4 Author: Nickolay Goppen Date: Wed Apr 29 12:30:09 2026 +0300 arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly [ Upstream commit 708ab9d3bc5b74eeee767c678366624d3c02a4ec ] Changing FastRPC compute-cbs' reg values to matching iommu streams solves SMMU translation errors when trying to use FastRPC on CDSP so change FastRPC compute-cbs' reg values that way Fixes: c0c32a9e3493 ("arm64: dts: qcom: sdm630/660: Add CDSP-related nodes") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Ekansh Gupta Signed-off-by: Nickolay Goppen Link: https://lore.kernel.org/r/20260429-qcom-sdm660-cdsp-adsp-fastrpc-dts-fix-v5-2-16bc82e622ad@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ddd6b01310a2b5d7234e5ddebec5725cbddcd910 Author: Yixun Lan Date: Tue Apr 28 10:57:29 2026 +0000 dts: riscv: spacemit: correct 32k clock frequency [ Upstream commit 3c350f6284d8ea5e7a9648241b2e9604f2262d42 ] The 32k oscillator's clock frequency is actually 32768Hz, so correct it. Fixes: 67072c8cd48c ("riscv: dts: spacemit: k3: add clock tree") Fixes: a6fafa64b03a ("riscv: dts: spacemit: Add clock tree for SpacemiT K1") Link: https://patch.msgid.link/20260428-06-k3-clk-osc32k-v1-1-e2378da7cb9b@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit e9b1ae1625cb776a3401d3af9b0aad496dd04456 Author: Wenmeng Liu Date: Thu Mar 19 17:09:02 2026 +0800 media: qcom: camss: vfe: fix PIX subdev naming on VFE lite [ Upstream commit c97e797a64cdfe4acecff831b4285418d2815893 ] VFE lite hardware does not provide a functional PIX path, but after the per sub-device type resource changes the PIX subdev name is still assigned unconditionally. Only assign the PIX subdev name on non-lite VFE variants to avoid exposing a misleading device name. Fixes: ae44829a4a97 ("media: qcom: camss: Add per sub-device type resources") Signed-off-by: Wenmeng Liu Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 91b00a6eb6d8a953663c8ffc52bbf9dc28de9482 Author: Leon Romanovsky Date: Fri May 1 09:35:06 2026 +0300 ntb: Use consistent DMA attributes when freeing DMA mappings [ Upstream commit 9d625aa2ebd445868955719e0abcf695b43f9318 ] The counterpart of dma_alloc_attrs() is dma_free_attrs(), which must receive the same DMA attributes used during allocation. The code previously used dma_free_coherent(), which does not accept or apply any DMA attributes. Fixes: 061a785a114f ("ntb: Force physically contiguous allocation of rx ring buffers") Signed-off-by: Leon Romanovsky Reviewed-by: Dave Jiang Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260501-dma-attrs-debug-v2-2-8dbac75cd501@nvidia.com Signed-off-by: Sasha Levin commit 10662aafce4acd52278c942d0a5b3993594017b9 Author: Leon Romanovsky Date: Fri May 1 09:35:05 2026 +0300 ntb: Store original DMA address for future release [ Upstream commit da6d997ac556479c112554ab5d95cbd04683eb11 ] The DMA API requires that dma_free_attrs receive the exact dma_handle originally returned by the allocation function. Do not modify it. Fixes: fc5d1829f9bf ("NTB: transport: Try harder to alloc an aligned MW buffer") Signed-off-by: Leon Romanovsky Reviewed-by: Dave Jiang Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260501-dma-attrs-debug-v2-1-8dbac75cd501@nvidia.com Signed-off-by: Sasha Levin commit 6e724f0e42cc87b0d8a9a4119a33e57f2d800f80 Author: Shuangpeng Bai Date: Thu May 7 11:50:21 2026 -0400 nilfs2: fix backing_dev_info reference leak [ Upstream commit 665f192a2a11384cb7dc1be5f87d16438522a4ed ] setup_bdev_super() already initializes sb->s_bdev and takes a reference on the block device backing_dev_info when assigning sb->s_bdi. nilfs_fill_super() takes another reference to the same backing_dev_info and stores it in sb->s_bdi again. The extra reference is not paired with a matching bdi_put(), since generic_shutdown_super() releases sb->s_bdi only once. Drop the redundant bdi_get() in nilfs_fill_super(). The single reference taken by setup_bdev_super() is enough and is released during superblock shutdown. Fixes: c1e012ea9e83 ("nilfs2: use setup_bdev_super to de-duplicate the mount code") Signed-off-by: Shuangpeng Bai Acked-by: Ryusuke Konishi Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 4d45250b1d22960f86d83245be188b16e456218b Author: Alexander Aring Date: Mon Apr 27 11:59:34 2026 -0400 dlm: fix add msg handle in send_queue ordered [ Upstream commit d2248cb70c070f8f04762872772e155b59016f17 ] In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue". The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore. Fixes: 489d8e559c659 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 2531c273f2e0a3010f59a8da0c14347328ec0012 Author: Lizhi Hou Date: Wed May 6 21:02:07 2026 -0700 accel/amdxdna: Fix clflush buffer size [ Upstream commit ada61841caede131cc626f6cd28a60904296f248 ] The firmware is told the buffer is req.buf_size bytes. It may read/write the entire region. If the CPU only flushes a subset, the remaining cache lines could contain stale data, causing the device to see garbage. Fixes: 6e87001fe19f ("accel/amdxdna: Adjust size for copy_to_user()") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260507040207.178111-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit d10c26bd628ae62f821818ab86433f3233e19a9c Author: Krzysztof Kozlowski Date: Sun Apr 12 19:12:48 2026 +0200 ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD [ Upstream commit 02802b40c31d2f2cfc94716189cfaf610930c589 ] QCOM_RPMH and QCOM_RPMHPD can be build only as modules when QCOM_COMMAND_DB is module itself. Fixes: 1c25ca9bb5c5 ("ARM: multi_v7_defconfig: enable more Qualcomm drivers") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 803591785d33cf13b6f73ce2796e8b9e6d5e6526 Author: Weiming Shi Date: Thu Apr 30 10:36:34 2026 -0700 crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents [ Upstream commit f7dd32c5179d7755de18e21d5674b08f9e5cb180 ] pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure. Fixes: af316fc442ef ("pefile: Digest the PE binary and compare to the PKCS#7 data") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b0fa9c1d6f6e4d2fe0007ddd7e8fd61a6d6aa9fd Author: Thorsten Blum Date: Sat May 2 21:09:04 2026 +0200 crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve [ Upstream commit 2d7b2cfc59998baf5e8622a24dc28f69a5212e06 ] The ->curve_oid check in ecrdsa_param_curve() rejects the valid enum value 0 (OID_id_dsa_with_sha1), but look_up_OID() returns OID__NR on lookup failure. Compare ->curve_oid with OID__NR instead to ensure that only unknown OIDs return -EINVAL. Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Signed-off-by: Thorsten Blum Reviewed-by: Lukas Wunner Reviewed-by: Vitaly Chikunov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 938ae1fb4a8f5db43b62b6206d409efbf317f0d9 Author: Lothar Rubusch Date: Sun Apr 26 21:29:47 2026 +0000 crypto: atmel-sha204a - fix blocking and non-blocking rng logic [ Upstream commit 319400fc5ee15db5793aa45f854968141326effc ] The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020 Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Suggested-by: Ard Biesheuvel Signed-off-by: Lothar Rubusch Tested-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9aeea4317696dc34304a58248d7f4d5912bec4dd Author: Tycho Andersen (AMD) Date: Wed Apr 8 08:32:59 2026 -0600 crypto: ccp - Initialize data during __sev_snp_init_locked() [ Upstream commit fed613c1230277105bb512bce6e1fda8f316d178 ] Sashiko notes: > is the stack variable data left uninitialized when taking the else branch? > Since data.tio_en is later evaluated unconditionally, could stack garbage > cause it to evaluate to true, leading to erroneous attempts to allocate > pages and initialize SEV-TIO on unsupported hardware? If the firmware is too old to support SEV_INIT_EX, data is left uninitialized but used in the debug logging about whether TIO is enabled or not. Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org Signed-off-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 17e1aae19a06d9f6da4b46d54fa2aeab77ec0c69 Author: Tycho Andersen (AMD) Date: Wed Apr 8 08:32:58 2026 -0600 crypto: ccp - Check for page allocation failure correctly in TIO [ Upstream commit a8d5370eef00eca132a292b1901c9914c817e385 ] Sashiko notes: > if __snp_alloc_firmware_pages() returns NULL under memory pressure, is it > safe to pass it directly to page_address()? > > On architectures without HASHED_PAGE_VIRTUAL, page_address(NULL) might > compute a deterministic but invalid, non-zero virtual address. The > subsequent if (tio_status) check would then evaluate to true, and > sev_tsm_init_locked() would dereference the invalid pointer. Indeed, page_address(NULL) will return non-NULL garbage here. Fix this by checking the page allocation itself for NULL, not the resulting virtual address. Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org Signed-off-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit af7341616b742ad2c374a90998bd650a035f694d Author: Tycho Andersen (AMD) Date: Wed Apr 8 08:32:57 2026 -0600 crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one [ Upstream commit 1b864b6cb213bbd7b406e9b2e98c962077f300df ] Sashiko notes: > regarding the bounds check in snp_filter_reserved_mem_regions() > called via walk_iomem_res_desc(): does the check > if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) > allow an off-by-one heap buffer overflow? > > If range_list->num_elements is 255, 255 * 16 + 8 = 4088, which is <= 4096. > Writing range->base (8 bytes) fills 4088-4095, but writing range->page_count > (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated > PAGE_SIZE buffer. Fix this by accounting for the entry about to be written to, in addition to the entries that are already allocated. Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org Signed-off-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d0c7bc211499cc429b01688c0ed7ba21035c9d6f Author: Tycho Andersen (AMD) Date: Wed Apr 8 08:32:56 2026 -0600 crypto: ccp - Reverse the cleanup order in psp_dev_destroy() [ Upstream commit 4a76a164ba1617f60d1c8a2fd754466c9d9e48e9 ] Before SNP x86 shutdown [1], all HV_FIXED pages were always leaked on module unload. Now pages can be reclaimed if they are freed before SNP shutdown. The SFS driver does sfs_dev_destroy() -> snp_free_hv_fixed_pages(), marking the command buffer as free. But this happens after sev_dev_destroy() in psp_dev_destroy(), so the pages are always leaked. Rearrange psp_dev_destroy() to destroy things in the reverse order from psp_init(), so that any dependencies can be unwound accordingly. This lets SFS free the page and the subsequent SNP shutdown release it. This was identified with use of Chris Mason's review-prompts: https://github.com/masoncl/review-prompts [1]: https://lore.kernel.org/all/20260324161301.1353976-1-tycho@kernel.org/ Fixes: 648dbccc03a0 ("crypto: ccp - Add AMD Seamless Firmware Servicing (SFS) driver") Reported-by: review-prompts Assisted-by: Claude:claude-4.6-opus Suggested-by: Tom Lendacky Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Ashish Kalra Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bb75bd7d9ae7672034f73ce67a57e6ac89bb39e5 Author: Di Shen Date: Mon Apr 27 20:00:47 2026 +0800 OPP: Fix race between OPP addition and lookup [ Upstream commit f5e1cc9a284bff2510981643a5bca4bc4c21b81a ] A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact(): CPU0 (add) CPU1 (lookup) ------------------------------- ------------------------------ _opp_add() mutex_lock() list_add(&new_opp->node, head) mutex_unlock() _opp_table_find_key() mutex_lock() dev_pm_opp_get(opp) kref_get() mutex_unlock() kref_init(&new_opp->kref) dev_pm_opp_put() kref_put_mutex() The newly added OPP is inserted into the list before its kref is initialized. A concurrent lookup can find this OPP and increment its reference count while it is still uninitialized, leading to refcount corruption and a potential premature free. Fix this by initializing ->kref and ->opp_table before making the OPP visible via list_add(). This ensures any concurrent lookup observes a fully initialized object. Fixes: 7034764a1e4a (PM / OPP: Add 'struct kref' to struct dev_pm_opp) Co-developed-by: Ling Xu Signed-off-by: Ling Xu Signed-off-by: Di Shen [ Viresh: Updated commit log ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 65a48d57bd282082fbc9eee4344c032b081dbc9c Author: Zhan Xusheng Date: Wed Apr 29 16:06:35 2026 +0800 alarmtimer: Remove stale return description from alarm_handle_timer() [ Upstream commit ed3b3c4976686b63b28e44f9805a88abc20ff18a ] alarm_handle_timer() was converted from returning enum alarmtimer_restart to void, but the kernel-doc "Return:" line was not removed. Remove the stale description. Fixes: 2634303f8773 ("alarmtimers: Remove return value from alarm functions") Signed-off-by: Zhan Xusheng Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260429080635.166790-1-zhanxusheng@xiaomi.com Signed-off-by: Sasha Levin commit 92be339a841f05ecebb77cd13a8fae7d0762a176 Author: Chris Brandt Date: Fri May 1 09:21:35 2026 -0400 drm: renesas: rz-du: mipi_dsi: Fix return path on error [ Upstream commit 79e1afecfe1afbfd06f63bf7bbe854a88155b7bd ] In case of error, we should unwind correctly. Switching to using dmam_ instead of dma_ and moving the code earlier fixes the issue. Fixes: 6f392f371650 ("drm: renesas: rz-du: Implement MIPI DSI host transfers") Suggested-by: Pavel Machek Signed-off-by: Chris Brandt Reviewed-by: Biju Das Link: https://patch.msgid.link/20260501132135.196701-1-chris.brandt@renesas.com Signed-off-by: Biju Das Signed-off-by: Sasha Levin commit ef44dac2a37f86eeae6b88ed10a6d60b35387dfd Author: Kuniyuki Iwashima Date: Sat May 2 03:12:59 2026 +0000 vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). [ Upstream commit 30a45c0bffdd62350261e2f2689fdba426a33578 ] udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init(). Fixes: 5602c48cf875 ("vxlan: change vxlan to use UDP socket GRO") Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-7-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1d701d9f4cb3684015c8119cfb08de68dfd162a3 Author: Peng Fan Date: Fri Apr 3 17:57:02 2026 +0800 Revert "arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal" [ Upstream commit 22465a195af370ed6311be3adee479fb7c683685 ] This reverts commit 39e4189d9d63a0b6fc15458ce0136e99ecdfb1b8. The board uses SDHC VSELECT to automatically switch between 1.8v and 3.3v. It does not use GPIO to control the PMIC SD_VSEL signal. The original commit intends to read back SD_VSEL value from GPIO, but it is wrong. When MUX is configured as SDHC VSELECT, it is impossible to read back the value from GPIO controller. Setting SION could only enable the input path for the mux function. It could not redirect the input to GPIO. Fixes: 39e4189d9d63a ("arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 7177583a7acc0e354c8c86302e7fb1682ee94172 Author: Peng Fan Date: Fri Apr 3 17:57:01 2026 +0800 Revert "arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal" [ Upstream commit aa907ee010e396c0c0d31d60495ace6e531ceec9 ] This reverts commit 8472751c4d96b558d60d0f6aede6b24b64bcb3c9. The board uses SDHC VSELECT to automatically switch between 1.8v and 3.3v. It does not use GPIO to control the PMIC SD_VSEL signal. The original commit intends to read back SD_VSEL value from GPIO, but it is wrong. When MUX is configured as SDHC VSELECT, it is impossible to read back the value from GPIO controller. Setting SION could only enable the input path for the mux function. It could not redirect the input to GPIO. And value "0x40000d0" is wrong, SION is BIT30, not BIT26. Fixes: 8472751c4d96b ("arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 958681b7bbffed784b77d8aa2c414d14e5788961 Author: Krzysztof Kozlowski Date: Mon Apr 6 08:38:13 2026 +0200 arm64: dts: imx8mp-ab2: Correct interrupt flags [ Upstream commit eb27f9b9a4b2965f8d497a3c565cfbc2473c184b ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING Correct the interrupt flags, assuming the author of the code wanted the same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW Fixes: bf68c18150ef ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Shengjiu Wang Reviewed-by: Daniel Baluta Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 1043f1e71ceac5cc4e56ab84cbcac476f99e0c19 Author: Krzysztof Kozlowski Date: Mon Apr 6 08:38:12 2026 +0200 arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags [ Upstream commit 7263f1acdd33169e1558064ee9a98758921f3bec ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING Correct the interrupt flags, assuming the author of the code wanted the same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Marek Vasut Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit b691f7477254b62c89265611bb0be56af6ad03f2 Author: Krzysztof Kozlowski Date: Mon Apr 6 08:38:11 2026 +0200 arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags [ Upstream commit 895e7756cdc1ba6467eb37eba31c1358243f6ad9 ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING Correct the interrupt flags, assuming the author of the code wanted the same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Marek Vasut Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8b35eda12ac0a234b43d1f20e2cea409a7dba9e4 Author: Peng Fan Date: Wed Apr 1 14:40:56 2026 +0800 arm64: dts: imx8x-colibri: Correct SODIMM PAD settings [ Upstream commit 0a03ee38a262cab0d9754e9947d565e089a9f7a5 ] SION is BIT(30), not BIT(26). Correct it. Fixes: 7ece3cbc8b1ef ("arm64: dts: colibri-imx8x: Add atmel pinctrl groups") Signed-off-by: Peng Fan Reviewed-by: Daniel Baluta Reviewed-by: Alexander Stein Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 358fc3d52a6413e7cc54b6e312236566ac5c887b Author: Weixin Guo <2298701336@qq.com> Date: Mon Apr 27 21:58:04 2026 +0800 arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc [ Upstream commit 460bac478c5fe69054ffc60d607bba03bcaf909b ] The RK809 PMIC interrupt pin on the Firefly ROC-RK3566-PC (Station M2) is physically connected to GPIO0_A3 (RK_PA3) according to the board's schematic. Currently, the PMIC node incorrectly specifies RK_PA7 for the interrupt, which prevents the PMIC from correctly signaling interrupts. (Note that the pinctrl node 'pmic_int' correctly configures RK_PA3). Fix this by updating the interrupts property to use RK_PA3. Fixes: 30ac9b4e25d8 ("arm64: dts: rockchip: add dts for Firefly Station M2 rk3566") Signed-off-by: Weixin Guo <2298701336@qq.com> Link: https://patch.msgid.link/tencent_5035EEE630C845B1B51DEA4284DE23DCCE06@qq.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 4952ddbe87735c38f717f78768071614dd4fd7d3 Author: Brian Norris Date: Tue Apr 28 13:06:53 2026 -0700 arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based /firmware [ Upstream commit 0b74f1a037672980c477bbe6b3848fb5341eb4f1 ] Chromium/Depthcharge bootloaders may dynamically add a few device nodes to a system's DTB under a /firmware node. A typical DT looks something like the following: ## From a RK3399 Gru/Kevin Chromebook: # find /sys/firmware/devicetree/base/firmware /sys/firmware/devicetree/base/firmware /sys/firmware/devicetree/base/firmware/coreboot /sys/firmware/devicetree/base/firmware/coreboot/ram-code /sys/firmware/devicetree/base/firmware/coreboot/compatible /sys/firmware/devicetree/base/firmware/coreboot/board-id /sys/firmware/devicetree/base/firmware/coreboot/reg /sys/firmware/devicetree/base/firmware/coreboot/name /sys/firmware/devicetree/base/firmware/chromeos /sys/firmware/devicetree/base/firmware/chromeos/readonly-firmware-version /sys/firmware/devicetree/base/firmware/chromeos/active-ec-firmware /sys/firmware/devicetree/base/firmware/chromeos/firmware-version /sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-storage /sys/firmware/devicetree/base/firmware/chromeos/vboot-shared-data /sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-size /sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-offset /sys/firmware/devicetree/base/firmware/chromeos/hardware-id /sys/firmware/devicetree/base/firmware/chromeos/compatible /sys/firmware/devicetree/base/firmware/chromeos/firmware-type /sys/firmware/devicetree/base/firmware/chromeos/fmap-offset /sys/firmware/devicetree/base/firmware/chromeos/name /sys/firmware/devicetree/base/firmware/ranges /sys/firmware/devicetree/base/firmware/name The /firmware node has an empty 'ranges', but does not have address/size-cells. Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") started requiring #address-cells for a device's parent if we want to use the reg resource in a device node. This leads to errors like the following: [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 Add appropriate #{address,size}-cells to work around the problem. Note that Google has also patched the Depthcharge bootloader source to add {address,size}-cells [1], but bootloader updates are typically delivered only via Google OS updates. Not all users install Google software updates, and even if they do, Google may not produce updated binaries for all/older devices. [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/ https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and #size-cells for firmware node") Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/ Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Reviewed-by: Chen-Yu Tsai [On RK3399-based Chromebooks there is no real other way than to load the DTB together with its kernel when running a mainline kernel and as the whole line is EOL, there also won't be any updates to the bootloader that could fix that issue there.] Link: https://patch.msgid.link/20260428200712.2660635-2-briannorris@chromium.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2f9f619d9ce0bf44db335ab97ea34158f0090e69 Author: Brian Norris Date: Tue Apr 28 13:06:54 2026 -0700 ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based /firmware [ Upstream commit 98461edf564a35ee00a97a64f5463eaece586546 ] Chromium/Depthcharge bootloaders may dynamically add a few device nodes to a system's DTB under a /firmware node. A typical DT looks something like the following: / { firmware { ranges; coreboot { compatible = "coreboot"; reg = <...>; ...; }; }; }; Notably, the /firmware node has an empty 'ranges', but does not have address/size-cells. Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") started requiring #address-cells for a device's parent if we want to use the reg resource in a device node. This leads to errors like the following: [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 Add appropriate #{address,size}-cells to work around the problem. Note that Google has also patched the Depthcharge bootloader source to add {address,size}-cells [1], but bootloader updates are typically delivered only via Google OS updates. Not all users install Google software updates, and even if they do, Google may not produce updated binaries for all/older devices. [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/ https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and #size-cells for firmware node") Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/ Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson [On RK288-based Chromebooks there is no real other way than to load the DTB together with its kernel when running a mainline kernel and as the whole line is EOL, there also won't be any updates to the bootloader that could fix that issue there.] Link: https://patch.msgid.link/20260428200712.2660635-3-briannorris@chromium.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 284ca8b314d7ef7851d929592d3452a79ddea83a Author: Duje Mihanović Date: Thu Apr 9 23:17:24 2026 +0200 arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen voltage [ Upstream commit 4da515eca1b8de56c9e8a17866626f99d9bccbc7 ] The old 1.9V setting was found to be insufficient in certain environments (in my case cold ones), causing the touchscreen to register ghost touches and mostly ignore actual touches. Increase the voltage to 2.5V to correct the issue. Fixes: ec958b5b18c8 ("arm64: dts: samsung,coreprimevelte: add touchscreen") Acked-by: Karel Balej Signed-off-by: Duje Mihanović Signed-off-by: Sasha Levin commit 2c74b677a82f6e45509467804330bd0c9b87978e Author: Conor Dooley Date: Tue May 5 11:22:50 2026 +0100 riscv: dts: microchip: fix pic64gx gpio interrupt-cells [ Upstream commit 48c7771b3c792b153872a2eff67e4cbcb77e4054 ] As the pic64gx devicetree files got added in parallel to the GPIO interrupt-cells being fixed for PolarFire SoC, they didn't get changed to the correct values. Fix them now. Fixes: 7219d20f9f421 ("riscv: dts: microchip: add pic64gx and its curiosity kit") Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 5aab3e1bac86f7d563e114673a1d57302bbe05c9 Author: Conor Dooley Date: Tue Apr 7 16:36:24 2026 +0100 riscv: dts: microchip: update pic64gx gpio interrupts to better match the SoC [ Upstream commit 4ce4a46cdb2404bcd53ca58a18aeda673f37fbe9 ] Just like PolarFire SoC, the same issues with GPIO interrupts exist in the pic64gx, due to their similarity. Yoinking from the commit message for the same change for PolarFire SoC: There are 3 GPIO controllers on this SoC, of which: - GPIO controller 0 has 14 GPIOs - GPIO controller 1 has 24 GPIOs - GPIO controller 2 has 32 GPIOs All GPIOs are capable of generating interrupts, for a total of 70. There are only 41 IRQs available however, so a configurable mux is used to ensure all GPIOs can be used for interrupt generation. 38 of the 41 interrupts are in what the documentation calls "direct mode", as they provide an exclusive connection from a GPIO to the PLIC. The 3 remaining interrupts are used to mux the interrupts which do not have a exclusive connection, one for each GPIO controller. The mux was overlooked when the bindings and driver were originally written for the GPIO controllers on Polarfire SoC, and the interrupts property in the GPIO nodes used to try and convey what the mapping was. Instead, the mux should be a device in its own right, and the GPIO controllers should be connected to it, rather than to the PLIC. Now that a binding exists for that mux, fix the inaccurate description of the interrupt controller hierarchy. Signed-off-by: Conor Dooley Stable-dep-of: 48c7771b3c79 ("riscv: dts: microchip: fix pic64gx gpio interrupt-cells") Signed-off-by: Sasha Levin commit b703c1d4686212a841284ed56fe26e52a529cb6c Author: David Heidelberg Date: Tue May 5 15:53:42 2026 +0200 drm/panel: Clean up S6E3HA2 config dependencies and fill help text [ Upstream commit 632a8aa96d0717aa92cb63e3939d09b896223b4c ] As per the config name this Display IC features a DSI command-mode interface (or the command to switch to video mode is not known/documented) and does not use any of the video-mode helper utilities, hence should not select VIDEOMODE_HELPERS. In addition it uses devm_gpiod_get() and related functions from GPIOLIB. Fixes: 779679d3c164 ("drm/panel: Add support for S6E3HA8 panel driver") Signed-off-by: David Heidelberg Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260505-panel-clean-up-kconfig-dep-v2-3-9cc31d6e6919@ixit.cz Signed-off-by: Sasha Levin commit ba4be84ab919f0292736a4cf1add35653508c95f Author: David Heidelberg Date: Tue May 5 15:53:41 2026 +0200 drm/panel: Clean up S6E3FC2X01 config dependencies [ Upstream commit faf497d2f1ff15756981c6e65a9c3d8bf192a969 ] As per the config name this Display IC features a DSI command-mode interface (or the command to switch to video mode is not known/documented) and does not use any of the video-mode helper utilities, hence should not select VIDEOMODE_HELPERS. In addition it uses devm_gpiod_get() and related functions from GPIOLIB. Fixes: 88148c30ef26 ("drm/panel: Add Samsung S6E3FC2X01 DDIC with AMS641RW panel") Signed-off-by: David Heidelberg Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260505-panel-clean-up-kconfig-dep-v2-2-9cc31d6e6919@ixit.cz Signed-off-by: Sasha Levin commit be7449e58ab6303b4e7f8182abdc2318846b5fc0 Author: Marijn Suijten Date: Tue May 5 15:53:40 2026 +0200 drm/panel: Clean up SOFEF00 config dependencies [ Upstream commit e87e2357292f80d10e1a43cb910454313a5cb448 ] As per the config name this Display IC features a DSI command-mode interface (or the command to switch to video mode is not known/documented) and does not use any of the video-mode helper utilities, hence should not select VIDEOMODE_HELPERS. In addition it uses devm_gpiod_get() and related functions from GPIOLIB. Fixes: 5933baa36e26 ("drm/panel/samsung-sofef00: Add panel for OnePlus 6/T devices") Reviewed-by: Neil Armstrong Reviewed-by: Casey Connolly Reviewed-by: David Heidelberg Signed-off-by: Marijn Suijten Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260505-panel-clean-up-kconfig-dep-v2-1-9cc31d6e6919@ixit.cz Signed-off-by: Sasha Levin commit 73dd28e41c6eeac2f984601e8f187bf6351ffe50 Author: Peddolla Harshavardhan Reddy Date: Mon Apr 20 14:38:44 2026 +0530 wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging [ Upstream commit bef9d5e378f07ccdf967b929897de84a9931d1e3 ] The lmr_feedback field is only applicable to TB and non-TB ranging. Currently, pmsr_parse_ftm() enforces lmr_feedback for all RSTA requests, incorrectly rejecting valid EDCA-based RSTA requests. Fix this by limiting the lmr_feedback requirement to TB and non-TB ranging only. Fixes: 853800c746d3 ("wifi: nl80211/cfg80211: support operating as RSTA in PMSR FTM request") Co-developed-by: Kavita Kavita Signed-off-by: Kavita Kavita Signed-off-by: Peddolla Harshavardhan Reddy Link: https://patch.msgid.link/20260420090856.2152905-2-peddolla.reddy@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4b9c05d21fdc0b31ff0255f24a6301b4daa7fba7 Author: Alice Ryhl Date: Thu Apr 16 13:10:54 2026 +0000 drm/gpuvm: take refcount on DRM device [ Upstream commit c2d72717e0a9dd01c6a1bac61a1462a8e04bd179 ] Currently GPUVM relies on the owner implicitly holding a refcount to the drm device, and it does not implicitly take a refcount on the drm device. This design is error-prone, so take a refcount on the device. Suggested-by: Danilo Krummrich Signed-off-by: Alice Ryhl Fixes: 546ca4d35dcc ("drm/gpuvm: convert WARN() to drm_WARN() variants") Link: https://patch.msgid.link/20260416-gpuvm-drm-dev-get-v1-1-f3bc06571e73@google.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 123b1729bb19b6f76c62baabb06d8298d8e33a1b Author: Marek Vasut Date: Wed Apr 22 23:07:23 2026 +0200 dt-bindings: vendor-prefixes: Add Displaytech Ltd. [ Upstream commit 42112cff8cb78ff6120983ba71bd14d52ce9dccd ] Add "displaytech" vendor prefix for Displaytech Ltd. . Signed-off-by: Marek Vasut Acked-by: Krzysztof Kozlowski Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260422210806.80948-1-marex@nabladev.com Signed-off-by: Sasha Levin commit 7ce97a9994aadbf9a12b23e80474afb0bc14ebb5 Author: Conor Dooley Date: Thu Mar 5 10:30:03 2026 +0000 riscv: dts: microchip: remove gpio hogs from beaglev-fire [ Upstream commit 7ab032833b2f0dd3b51d71e6756ebe7efc61eed4 ] sd-det-hog should be cd-gpios, but when the mmc-spi-slot was added, the "cd-" prefix was omitted and the collision with the hog was not noticed. vio-enable-hog is just a regulator that can be modelled as such. Fixes: 1088d49b62648 ("riscv: dts: microchip: enable qspi adc/mmc-spi-slot on BeagleV Fire") Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 1b7b645d7730f47bef4d072ee7fc599a34169216 Author: Conor Dooley Date: Thu Mar 19 16:26:35 2026 +0000 riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells [ Upstream commit 79b731da340f1c9703e28665d49a865aa6956278 ] The platform has variable interrupt types for GPIO interrupts, in addition to having multiple lines per GPIO controller. Two interrupt cells are required. Fixes: 528a5b1f2556d ("riscv: dts: microchip: add new peripherals to icicle kit device tree") Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 8addeb8537800d3f5c0caa2da76e1678a5d6a617 Author: Felix Gu Date: Mon May 4 22:53:26 2026 +0800 pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path [ Upstream commit 334f7bcbdc79dc8e5b938ac3372453a5368221cf ] In the error path of sunxi_pmx_request(), the code calls regulator_put(s_reg->regulator) to release the regulator. However, s_reg->regulator is only assigned after a successful regulator_enable(). This causes a memory leak: the regulator obtained via regulator_get() is never properly released when regulator_enable() fails. Fixes: dc1445584177 ("pinctrl: sunxi: Fix and simplify pin bank regulator handling") Signed-off-by: Felix Gu Reviewed-by: Andre Przywara Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c0f6acb33d46c6d4add01bcfc7376cfeea1276bc Author: Conor Dooley Date: Thu Apr 30 19:52:12 2026 +0100 dts: spacemit: set console baud rate on bpif3 [ Upstream commit 24c12ca43b12c104389d9a159207d0b25779d0af ] Because the default console's baud rate is not set, defconfig kernels do not have any serial output on this platform. Set the baud rate to 115200, matching what is used by U-Boot etc on this platform. Suggested-by: Vivian Wang Fixes: d60d57ab6b2a8 ("riscv: dts: spacemit: add Banana Pi BPI-F3 board device tree") Signed-off-by: Conor Dooley Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20260430-reword-overstep-3be08b7eab25@spud Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 377c3ce5d83fb96e20e92282f788931c5d5850e8 Author: Masami Hiramatsu (Google) Date: Thu Mar 26 21:12:00 2026 +0900 lib/vsprintf: Fix to check field_width and precision [ Upstream commit 71876dffab295b6e25d4209f0424da8fc5020e12 ] Check the field_width and presition correctly. Previously it depends on the bitfield conversion from int to check out-of-range error. However, commit 938df695e98d ("vsprintf: associate the format state with the format pointer") changed those fields to int. We need to check the out-of-range correctly without bitfield conversion. Fixes: 938df695e98d ("vsprintf: associate the format state with the format pointer") Reported-by: David Laight Closes: https://lore.kernel.org/all/20260318151250.40fef0ab@pumpkin/ Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Petr Mladek Link: https://patch.msgid.link/177452712047.197965.16376597502504928495.stgit@devnote2 Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit c38445d726ed9d5dc89cdb6cedafdad5affde56d Author: Damian Muszynski Date: Tue Apr 7 12:04:26 2026 +0200 crypto: qat - fix heartbeat error injection [ Upstream commit 2e96024632b386c86860aa78639940fc96d6fcc9 ] The current implementation of the heartbeat error injection uses adf_disable_arb_thd() to stop a specific accelerator engine thread from processing requests. This does not reliably prevent the device from generating responses. Fix the error injection by disabling the device arbiter through exit_arb() instead. This properly simulates a device failure by stopping all arbitration, which results in missing responses for sent requests. Remove the now unused adf_disable_arb_thd() function and its declaration. Fixes: e2b67859ab6e ("crypto: qat - add heartbeat error simulator") Signed-off-by: Damian Muszynski Reviewed-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f71a8795990a516a18bb95b7ed3de4a19317a652 Author: Josh Poimboeuf Date: Thu Apr 2 19:08:39 2026 -0700 klp-build: Fix patch cleanup on interrupt [ Upstream commit f3048888ea62ac1c573db91e74e0dcabe058e89f ] If a build error occurs and the user hits Ctrl-C while a large patch is being reverted during cleanup, the cleanup EXIT trap gets re-triggered and tries to re-revert the already partially-reverted patch. That causes 'patch -R' to repeatedly prompt "Unreversed patch detected! Ignore -R? [n]" for each already-reverted hunk, with no way to break out. Fix it by adding '--force' to the patch revert command in revert_patch(), which causes it to silently ignore already-reverted hunks. And ignore errors, as the cleanup is always best-effort. For similar reasons, add to APPLIED_PATCHES before (rather than after) applying the patch in apply_patch() so an interrupted apply will also get cleaned up. Fixes: d36a7343f4ba ("livepatch/klp-build: switch to GNU patch and recountdiff") Acked-by: Song Liu Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 4165b2f6491681d2921a0a47b26cf3263e02b3d1 Author: Josh Poimboeuf Date: Fri Apr 10 21:49:56 2026 -0700 klp-build: Fix checksum comparison for changed offsets [ Upstream commit ba77fe55781a2464f68b6c13b4b31d05abd2abcf ] The klp-build -f/--show-first-changed feature uses diff to compare checksum log lines between original and patched objects. However, diff compares entire lines, including the offset field. When a function is at a different section offset, the offset field differs even though the instruction checksum is identical, causing the wrong instruction to be printed. Only compare the checksum field when looking for the first changed instruction. Also print both the original and patched offsets when they differ. Fixes: 78be9facfb5e ("livepatch/klp-build: Add --show-first-changed option to show function divergence") Acked-by: Song Liu Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 653421ada35c03085fd5066e1ad041ae6dad3fdd Author: Josh Poimboeuf Date: Thu Apr 2 19:47:10 2026 -0700 klp-build: Fix hang on out-of-date .config [ Upstream commit cc39ccce7d5bc623100f07dcda070cef1bf690f6 ] If .config is out of date with the kernel source, 'make syncconfig' hangs while waiting for user input on new config options. Detect the mismatch and return an error. Fixes: 6f93f7b06810 ("livepatch/klp-build: Fix inconsistent kernel version") Acked-by: Song Liu Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 7c558e3d80daf9351573ace236bfa9b695fe20a3 Author: Josh Poimboeuf Date: Tue Apr 21 07:21:19 2026 -0700 objtool: Fix reloc hash collision in find_reloc_by_dest_range() [ Upstream commit a375e327b63e0da29b82a92b569bfdf4628fa38a ] In find_reloc_by_dest_range(), hash collisions can cause a high-offset relocation to appear when probing a low-offset hash bucket. Only return early when the best match found so far genuinely belongs to the current bucket (its offset is within the bucket's stride range). Otherwise, continue scanning later buckets which may contain lower-offset matches. This ensures the first reloc in the range gets returned. Fixes: 74b873e49d92 ("objtool: Optimize find_rela_by_dest_range()") Acked-by: Peter Zijlstra (Intel) Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit a5ad716141904c4b87bb55b0f7a9e5acbd9f8d8d Author: Josh Poimboeuf Date: Sun Apr 12 22:41:23 2026 -0700 objtool: Replace iterator callback with for_each_sym_by_mangled_name() [ Upstream commit 0333b7399587ee0aaa863ed0d13a00a6c7c64068 ] Convert the callback-based iterate_sym_by_demangled_name() with a new for_each_sym_by_demangled_name() macro. This eliminates the callback struct/function and makes the code more compact and readable. Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Stable-dep-of: a375e327b63e ("objtool: Fix reloc hash collision in find_reloc_by_dest_range()") Signed-off-by: Sasha Levin commit 4220dd46c38e7e0de613eef21f44a72be0e316ac Author: Josh Poimboeuf Date: Mon Apr 20 22:59:12 2026 -0700 objtool/klp: Fix relocation conversion failures for R_X86_64_NONE [ Upstream commit 3787e82a4e3a0a04aeb5543580ee90bed3a36e55 ] Objtool has some hacks which NOP out certain calls/jumps and replace their relocations with R_X86_64_NONE. The klp-diff relocation extraction code will error out when trying to copy these relocations due to their negative addend, which would only makes sense for a PC-relative branch instruction. Just ignore them. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit cf0fac29f54073e61caa9ea4d8dc618a8333b092 Author: Josh Poimboeuf Date: Fri Apr 3 14:53:32 2026 -0700 objtool/klp: Fix extraction of text annotations for alternatives [ Upstream commit 62a7a01fde87c99926cd7e9670b4226c4c79ebaf ] Objtool is failing to extract text annotations which reference .altinstr_replacement instructions: 1) Alternative replacement fake symbols are NOTYPE rather than FUNC, and they don't have sym->included set, thus they aren't recognized by should_keep_special_sym(). 2) .discard.annotate_insn gets processed before .altinstr_replacement, so the referenced (fake) symbols don't have clones yet. Fix the first issue by checking for a valid clone instead of sym->included and by accepting NOTYPE symbols when processing .discard.annotate_insn. Fix the second issue by deferring text annotation processing until after the other special sections have been cloned. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit e9a4ea48396e74d1eec05506c23aae0ed764d529 Author: Josh Poimboeuf Date: Thu Apr 9 18:35:01 2026 -0700 objtool/klp: Fix cloning of zero-length section symbols [ Upstream commit 98377f3ba7c02d6eb34e203c9f9823bc62b0d231 ] Fix NULL dereference when cloning a symbol from an empty section. sec->data is only populated for sections with non-zero size. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 283caf6959f4d5c7d3082208edc315283b3080f4 Author: Josh Poimboeuf Date: Thu Apr 9 18:34:50 2026 -0700 objtool/klp: Fix handling of zero-length .altinstr_replacement sections [ Upstream commit c4c02d4450b5b7e2fbde578252f71a5697180112 ] When a section is empty (e.g. only zero-length alternative replacements), there are no symbols to convert a section symbol reference to. Skip the reloc instead of erroring out. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 9dea59f904b30811ef5c3c58c909010255947d6d Author: Joe Lawrence Date: Tue Mar 24 17:34:16 2026 -0400 objtool/klp: Fix create_fake_symbols() skipping entsize-based sections [ Upstream commit 3de711fba73ad93b8b3fbe09cf681cefed5d573d ] create_fake_symbols() has two phases: creating symbols from ANNOTATE_DATA_SPECIAL entries, and a fallback that uses sh_entsize for special sections like .static_call_sites. When .discard.annotate_data is absent, the function returns early, skipping the entsize fallback and silently allowing unsupported module-local static call keys through. Fix it by jumping to the entsize phase instead of returning early. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Assisted-by: Claude:claude-4-opus Signed-off-by: Joe Lawrence Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit a19f83ec8699784082baff132db881f893d5019f Author: Josh Poimboeuf Date: Sat Apr 11 21:11:24 2026 -0700 objtool/klp: Fix .data..once static local non-correlation [ Upstream commit ff529864e738f447ff4c019956319930fc274a23 ] While there was once a section named .data.once, it has since been renamed to .data..once with commit dbefa1f31a91 ("Rename .data.once to .data..once to fix resetting WARN*_ONCE"). Fix it. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit db3172a18cce1e6ac48bdc052788547a3977c177 Author: Joe Lawrence Date: Wed Apr 8 10:49:19 2026 -0400 objtool/klp: Fix is_uncorrelated_static_local() for Clang [ Upstream commit 84c304a534b844703d3437811e8f072166e3f116 ] For naming function-local static locals, GCC uses ., e.g. __already_done.15, while Clang uses . with optional ., e.g. create_worker.__already_done.111 The existing is_uncorrelated_static_local() check only matches the GCC convention where the variable name is a prefix. Handle both cases by checking for a prefix match (GCC) and by checking after the first dot separator (Clang). Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Signed-off-by: Joe Lawrence Acked-by: Song Liu Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 3255998ad0106df5a2943ba1c146e7f3c6e9c9d6 Author: Ashish Mhetre Date: Thu Apr 30 09:52:01 2026 +0000 memory: tegra: Wire up system sleep PM ops [ Upstream commit 2411c8d1e3e09910e94bab0d0a2c071fbc8a9e7b ] The tegra-mc platform driver does not register any dev_pm_ops, so the SoC-specific ->resume() is never invoked (e.g. tegra186_mc_resume) on system wake. On Tegra186 and later this means MC client Stream-ID override registers are not reprogrammed, and clients behind the ARM SMMU fault on the first DMA after resume. Register a dev_pm_ops on the tegra-mc driver and route the system resume callback into mc->soc->ops->resume() so the existing SID restore path runs again on wake. No suspend callback is needed as the resume path reprograms all MC state from the static SoC tables, so there is nothing to save. Fixes: fe3b082a6eb8 ("memory: tegra: Add SID override programming for MC clients") Signed-off-by: Ashish Mhetre Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260430095202.1167651-3-amhetre@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 48213cbfa6dd3d3719859e1cb9a1bc2e7a45c25f Author: Icenowy Zheng Date: Tue Mar 31 14:01:25 2026 +0800 drm: verisilicon: call atomic helper's plane state check even if no CRTC [ Upstream commit eae3903e33797a28d0d37e693d4314d58338918e ] The `drm_atomic_helper_check_plane_state()` helper function needs to be called even if the plane is bound to no CRTCs. Remove the early return in the primary plane's atomic_check, and use NULL for crtc_state in this situation. Fixes: dbf21777caa8 ("drm: verisilicon: add a driver for Verisilicon display controllers") Signed-off-by: Icenowy Zheng Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260331060126.1291966-4-zhengxingda@iscas.ac.cn Signed-off-by: Sasha Levin commit f4de1cc282e578d703b9a5da8a8a416c11f5b39f Author: Nas Chung Date: Wed Apr 15 18:25:21 2026 +0900 media: v4l2-common: Add YUV24 format info [ Upstream commit 968b741872914a15363af0daf24ed2e82ec355f3 ] The YUV24 format is missing an entry in the v4l2_format_info(). The YUV24 format is the packed YUV 4:4:4 formats with 8 bits per component. Fixes: 0376a51fbe5e ("media: v4l: Add packed YUV444 24bpp pixel format") Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 984c22a861eef904ed2e369d16ace0d559b98999 Author: Samuel Holland Date: Tue Apr 7 01:14:40 2026 +0300 media: cedrus: Fix failure to clean up hardware on probe failure [ Upstream commit f0a22f1d602ed499a192284de5e811a73421f0c7 ] If V4L2 device fails to register, then SRAM still be claimed and as a result driver will not be able to probe again. cedrus 1c0e000.video-codec: Failed to claim SRAM cedrus 1c0e000.video-codec: Failed to probe hardware cedrus 1c0e000.video-codec: probe with driver cedrus failed with error -16 cedrus_hw_remove undoes everything that was previously done by cedrus_hw_probe, such as disabling runtime power management and releasing the claimed SRAM and reserved memory region. Signed-off-by: Samuel Holland Signed-off-by: Andrey Skvortsov Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Acked-by: Paul Kocialkowski Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ccaf1a97e15589b6f1748199ab23254c108b8057 Author: Felix Gu Date: Mon Feb 23 19:59:20 2026 +0800 watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register failure [ Upstream commit 96b3cfc3b8ad0524d12fed1e08bc5df3ff345f64 ] The driver uses devm_add_action_or_reset() to register sprd_wdt_disable() as a managed cleanup action. When devm_watchdog_register_device() fails, the devm core will invoke the cleanup action automatically. The explicit sprd_wdt_disable() call in the error path is therefore redundant and results in adouble cleanup. Fixes: 78d9bfad2e89 ("watchdog: sprd_wdt: Convert to use device managed functions and other improvements") Signed-off-by: Felix Gu Reviewed-by: Guenter Roeck Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/20260223-sprd_wdt-v1-1-2e71f9a76ecb@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6e8ea05b73f6f031f9a8a0018693a4f29b442e48 Author: Balakrishnan Sambath Date: Mon Mar 2 17:03:09 2026 +0530 watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5 [ Upstream commit e8bc610b14a99d24b0916635102cc52ba41def9b ] The driver hardcoded AT91_WDT_WDDIS (bit 15) in wdt_enabled and the probe initial state readout. SAM9X60 and SAMA7G5 use bit 12 (AT91_SAM9X60_WDDIS), causing incorrect WDDIS detection. Introduce a per-device wddis_mask field to select the correct WDDIS bit based on the compatible string. Fixes: 266da53c35fc ("watchdog: sama5d4: readout initial state") Co-developed-by: Andrei Simion Signed-off-by: Andrei Simion Signed-off-by: Balakrishnan Sambath Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20260302113310.133989-2-balakrishnan.s@microchip.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit a4f833321e513e43bd19053a211c8d1d10888621 Author: Yingjie Gao Date: Thu Apr 2 15:16:17 2026 +0800 watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH [ Upstream commit 4f675f036cd5e9cfbe6df5f24f8338158af96a4b ] Commit 009637de1f65 ("watchdog: sp5100_tco: support Hygon FCH/SCH (Server Controller Hub)") added Hygon vendor matching to the efch layout selection, but newer Hygon 0x790b SMBus devices still need the efch_mmio path. The efch_mmio path enables EFCH_PM_DECODEEN_WDT_TMREN before probing the watchdog MMIO block. If firmware leaves that bit clear and the driver picks the legacy efch path instead, probe falls back to the alternate window and fails with "Watchdog hardware is disabled". Select efch_mmio for Hygon 0x790b devices with revision 0x51 or later, matching the equivalent AMD behavior and allowing the watchdog to initialize on those systems. Fixes: 009637de1f65 ("watchdog: sp5100_tco: support Hygon FCH/SCH (Server Controller Hub)") Signed-off-by: Yingjie Gao Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20260402071617.634563-2-gaoyingjie@uniontech.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ffb693966d967addb53eff9805b1af2fe3d987bb Author: Gabriele Monaco Date: Mon Apr 27 15:17:09 2026 +0200 Documentation/rv: Replace stale website link [ Upstream commit 49cbd359e4a7501e9d6694c072031d9ae6b2d1a5 ] The sched monitor page was linking to Daniel's website which is now down. The main purpose of the link was to point to a source for the models from the original author and that can be found also in his published paper. Replace the link with a reference to Daniel's "A thread synchronization model for the PREEMPT_RT Linux kernel" which can be found online and includes the models definitions as well as the work behind them (not the original patches but since they're based on a 5.0 kernel and are mostly included upstream, there's little value in keeping them in the docs). Fixes: 03abeaa63c08 ("Documentation/rv: Add docs for the sched monitors") Signed-off-by: Gabriele Monaco Acked-by: Matteo Martelli Tested-by: Matteo Martelli Tested-by: Randy Dunlap Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260427131709.170505-2-gmonaco@redhat.com> Signed-off-by: Sasha Levin commit eb49026306b4fdf32946a66211d51f65928894d2 Author: Aleksandr Loktionov Date: Thu Apr 30 23:37:20 2026 -0700 ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550() [ Upstream commit eae23ec14a9c83b6af9bd616f3b86163688e2688 ] ixgbe_host_interface_command() treats its buffer as a u32 array. The local buffer we pass in was a union of byte-sized fields, which gives it 1-byte alignment on the stack. On strict-align architectures this can cause unaligned 32-bit accesses. Add a u32 member to union ixgbe_hic_hdr2 so the object is 4-byte aligned, and pass the u32 member when calling ixgbe_host_interface_command(). No functional change on x86; prevents unaligned accesses on architectures that enforce natural alignment. Fixes: 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type") Signed-off-by: Aleksandr Loktionov Reviewed-by: Jedrzej Jagielski Reviewed-by: Paul Menzel Fixes: 6a14ee0cfb19 ("ixgbe: Add X550 support function pointers") Tested-by: Rinitha S Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-9-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54ebf6af5805f7984d22f380a28bed48c34ce009 Author: Jihed Chaibi Date: Wed Mar 25 23:34:11 2026 +0100 ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint [ Upstream commit 2bc564f46b00dc4f4331fc337277ff3f5fac8a4e ] The cpu_endpoint in mcasp0 specifies the TLV320AIC3106 codec as the bitclock and frame master, but the phandles point to the codec's port node (codec_port) rather than its endpoint node (codec_endpoint). audio-graph-card calls simple_util_parse_daifmt() with ep_codec set to the endpoint node (codec_endpoint). The function resolves the bitclock-master phandle and checks whether it equals ep_codec. Since codec_port is the parent of codec_endpoint, not the endpoint itself, the comparison always evaluates to false. This causes the mcasp0 CPU side to be silently configured as bitclock and frame master instead of the codec, which is the opposite of the intended configuration. Fix by pointing bitclock-master and frame-master to codec_endpoint. Fixes: e5f89dbdebc5 ("ARM: dts: am335x-sl50: use audio-graph-card for sound") Signed-off-by: Jihed Chaibi Link: https://patch.msgid.link/20260325223411.123666-1-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit 53dd29e8aeb2a1b5f079178551836b85fc6b53df Author: Wei Zhang Date: Fri Apr 3 21:30:50 2026 -0700 wifi: ath11k: cancel SSR work items during PCI shutdown [ Upstream commit 8c79aac429b583301f387374ff37c59be671df87 ] A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources. Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence. Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once. Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855") Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support") Signed-off-by: Wei Zhang Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260404043050.3433754-1-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 336d4c8cd9b1646060ee690c881d465dfc09c6c0 Author: Tristan Madani Date: Wed Apr 15 22:23:43 2026 +0000 wifi: ath9k: fix OOB access from firmware tx status queue ID [ Upstream commit 7ce2f118a2389e8f0a64068c6fe7cc7d40639be0 ] ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index. Fixes: fce041beb03f ("ath9k: unify edma and non-edma tx code, improve tx fifo handling") Signed-off-by: Tristan Madani Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260415222343.1540564-1-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0cc7c35a481014cbe4d0c89f6801305e87bbe04a Author: Chen-Yu Tsai Date: Mon Apr 27 10:11:46 2026 +0800 pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask() [ Upstream commit 3ca99eed042620d12315e9272ed3ef260ca29877 ] When support for multiple EINT base addresses was added in commit 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple addresses"), mtk_eint_chip_write_mask() was changed to write interrupt masks for all base addresses in one call. However the "base" parameter was left around and now causes sparse warnings: mtk-eint.c:428:44: warning: incorrect type in argument 2 (different address spaces) mtk-eint.c:428:44: expected void [noderef] __iomem *base mtk-eint.c:428:44: got void [noderef] __iomem **base mtk-eint.c:436:44: warning: incorrect type in argument 2 (different address spaces) mtk-eint.c:436:44: expected void [noderef] __iomem *base mtk-eint.c:436:44: got void [noderef] __iomem **base Since the "base" parameter is no longer needed, just drop it. Fixes: 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple addresses") Cc: Hao Chang Cc: Qingliang Li Signed-off-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b5d2240c2c7bc8370e7ba54a2e1fe3919f55aee5 Author: Prasanna Kumar T S M Date: Thu Mar 19 23:04:45 2026 -0700 soc: xilinx: Shutdown and free rx mailbox channel [ Upstream commit fdee7c66c0d7b6869c36b9f9a915abf29ab5b550 ] A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly. Fixes: ffdbae28d9d1a ("drivers: soc: xilinx: Use mailbox IPI callback") Signed-off-by: Prasanna Kumar T S M Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260320060445.1541017-1-ptsm@linux.microsoft.com Signed-off-by: Sasha Levin commit d349aa118ff5e4cab88424ce1b16e08edd70f8bb Author: Prasanna Kumar T S M Date: Thu Mar 19 23:03:06 2026 -0700 soc: xilinx: Fix race condition in event registration [ Upstream commit fb445935338405110baca8f541a2df3b4cb8d712 ] The zynqmp_power driver registers handlers for suspend and subsystem restart events using register_event(). However, the work structures (zynqmp_pm_init_suspend_work and zynqmp_pm_init_restart_work) used by these handlers were allocated and initialized after the registration call. This created a race window where, if the firmware triggered an event immediately after registration but before allocation, the callback (suspend_event_callback or subsystem_restart_event_callback) would dereference a NULL pointer in work_pending(), leading to a crash. Fix this by allocating and initializing the work structures before registering the events. Fixes: fcf544ac6439 ("soc: xilinx: Add cb event for subsystem restart") Signed-off-by: Prasanna Kumar T S M Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260320060306.1540928-1-ptsm@linux.microsoft.com Signed-off-by: Sasha Levin commit b0dad1ac5e2f725c9a131060b873f8757c82c3fa Author: Xingjing Deng Date: Fri Mar 6 02:17:09 2026 +0000 kconfig: fix potential NULL pointer dereference in conf_askvalue [ Upstream commit b9d21c32dca2167a614e66c9e27999b9e1c33d55 ] In conf_askvalue(), the 'def' argument (retrieved via sym_get_string_value) can be NULL. While current call sites ensure that 'def' is valid, calling printf("%s\n", def) is technically undefined behavior and could lead to a segmentation fault on certain libc implementations if the function were called with a NULL pointer in the future. Improve the robustness of conf_askvalue() by providing an empty string as a fallback. Additionally, remove the redundant re-initialization of the 'line' buffer inside the !sym_is_changeable(sym) block, as it is already properly initialized at the function entry. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xingjing Deng Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260306021709.27068-1-micro6947@gmail.com Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 920101305e7601a33b9e01019f4ca526af2526ae Author: Tristan Madani Date: Tue Apr 21 11:14:42 2026 +0000 wifi: rtw89: add bounds check on firmware mac_id in link lookup [ Upstream commit 6d88244bb129755acca696f9227200f4a2d106a6 ] The mac_id field in RX descriptors is 8 bits wide (0-255), but assoc_link_on_macid[] has only RTW89_MAX_MAC_ID_NUM (128) entries. While the driver currently assigns mac_id values below 128, the descriptor value comes from firmware and is not validated before use as an array index. Add a defensive bounds check in rtw89_assoc_link_rcu_dereference() to guard against out-of-range firmware values. Fixes: 144c6cd24b35 ("wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports") Signed-off-by: Tristan Madani Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260421111442.3395411-1-tristmd@gmail.com Signed-off-by: Sasha Levin commit 1554fa522f16ec7c5c342ad33fe734eeb6eb2452 Author: Tristan Madani Date: Tue Apr 21 11:14:34 2026 +0000 wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer [ Upstream commit 6e76e9ed273dfb4b3333a5ebbb94958cc5752ab6 ] In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Tristan Madani Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260421111434.3389674-1-tristmd@gmail.com Signed-off-by: Sasha Levin commit 140fa699cfd0e18ab2f1497acd951fb3548610f5 Author: Shin-Yi Lin Date: Mon Apr 20 11:40:41 2026 +0800 wifi: rtw89: Correct data type for scan index to avoid infinite loop [ Upstream commit 08fdcb529df6df3562dd2b0035f88dd5be8b3c68 ] A kernel soft lockup was observed during Wi-Fi scanning on the 6GHz band. The CPU becomes stuck in rtw89_hw_scan_add_chan_ax for over 20 seconds, leading to a system panic. RIP points to 0f b6 c3 (movzbl %bl, %eax), which zero-extends the low 8 bits of RBX into RAX. RBX (the counter i) has reached a huge value: 0x137466a1. watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u16:4:6124] Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] RIP: 0010:rtw89_hw_scan_add_chan_ax+0xb3/0x6e0 [rtw89_core] Code: a0 48 89 45 a8 44 89 6d 9c 44 89 75 98 eb 29 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 c3 01 <0f> b6 c3 41 3b 44 24 74 0f 83 0b 02 00 00 0f b6 c3 48 8d 14 80 49 RSP: 0018:ffffcb48cbaa39f8 EFLAGS: 00000202 RAX: 0000000000000005 RBX: 00000000137466a1 RCX: 0000000000000000 RDX: ffff89ffc9d851a8 RSI: 0000000000004f0d RDI: 0000000096af0130 RBP: ffffcb48cbaa3a60 R08: 0000000000000000 R09: ffff8a00b7502080 R10: ffff8a00b75ff600 R11: 0000000000000000 R12: ffff89ffc7553870 R13: ffff8a00b7ac8f19 R14: ffff8a00b75020d8 R15: ffff89ffc3d54d80 FS: 0000000000000000(0000) GS:ffff8a014f962000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007558d7f9f4c4 CR3: 0000000178040001 CR4: 00000000001706f0 Call Trace: rtw89_hw_scan_prep_chan_list_ax+0x8a/0x400 [rtw89_core] rtw89_hw_scan_start+0x546/0x8a0 [rtw89_core] ? rtw89_fw_h2c_default_cmac_tbl+0x13c/0x1f0 [rtw89_core] rtw89_ops_hw_scan+0xae/0x120 [rtw89_core] drv_hw_scan+0xbb/0x180 [mac80211] __ieee80211_start_scan+0x2fc/0x750 [mac80211] ieee80211_request_scan+0xe/0x20 [mac80211] ieee80211_scan+0x123/0x190 [mac80211] rdev_scan+0x40/0x110 [cfg80211] cfg80211_scan_6ghz+0x5a1/0xa30 [cfg80211] By objdump with source: for (i = 0; i < req->n_6ghz_params; i++) { 5fbc0: 83 c3 01 add $0x1,%ebx --> i++ 5fbc3: 0f b6 c3 movzbl %bl,%eax --> get counter fbc6: 41 3b 44 24 74 cmp 0x74(%r12),%eax * RBX: 00000000137466a1 -> %bl = a1 -> EAX = 000000a1 (161) Fixes: c6aa9a9c4725 ("wifi: rtw89: add RNR support for 6 GHz scan") Signed-off-by: Shin-Yi Lin Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260420034051.17666-7-pkshih@realtek.com Signed-off-by: Sasha Levin commit d7920797f721f944861f3c48ffb2b73f84b631fe Author: Chin-Yen Lee Date: Mon Apr 13 14:59:26 2026 +0800 wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers [ Upstream commit 706183dbef4a79d120d4e928f693bea50df496f8 ] rtw88 stores an ieee80211_hw pointer via pci_set_drvdata() at probe time, but io_error_detected() and io_resume() retrieve it as a net_device pointer. This causes netif_device_detach/attach to operate on an ieee80211_hw struct, reading and writing at wrong offsets. Use ieee80211_stop_queues/wake_queues instead, consistent with every other queue stop/start path in the driver. Fixes: cdb82c80b934 ("wifi: rtw88: pci: add PCI Express error handling") Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260413065926.17027-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit c1907b9a4fa9cb33d11a9af138374dd2e93f7a93 Author: Christos Longros Date: Sun Mar 29 09:38:57 2026 +0200 wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers [ Upstream commit 7068c379cf9aa8afe4dce4d9d82390187aa9c4d0 ] rtw89 stores an ieee80211_hw pointer via pci_set_drvdata() at probe time, but io_error_detected() and io_resume() retrieve it as a net_device pointer. This causes netif_device_detach/attach to operate on an ieee80211_hw struct, reading and writing at wrong offsets. The adjacent io_slot_reset() already does it correctly. Use ieee80211_stop_queues/wake_queues instead, consistent with every other queue stop/start path in the driver. Tested on RTL8852CE by calling the handlers from a test module before and after the fix. Fixes: 16e3d93c6183 ("wifi: rtw89: pci: add PCI Express error handling") Signed-off-by: Christos Longros Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260329073857.113081-1-chris.longros@gmail.com Signed-off-by: Sasha Levin commit 9b0f4082a09760939588135d60a8e9cc994bfa3e Author: Danilo Krummrich Date: Sat Apr 18 18:22:18 2026 +0200 driver core: use READ_ONCE() for dev->driver in dev_has_sync_state() [ Upstream commit e9506871a8ea304cde48ff4a57226df2aadddae3 ] dev_has_sync_state() reads dev->driver twice without holding device_lock() -- once for the NULL check and once to dereference ->sync_state. Some callers only hold device_links_write_lock, which doesn't prevent a concurrent unbind from clearing dev->driver via device_unbind_cleanup(). Fix it by reading dev->driver exactly once with READ_ONCE(), pairing with the WRITE_ONCE() in device_set_driver(). Link: https://lore.kernel.org/driver-core/DHW8QPU1VU1F.3P6PH69HLFBYC@kernel.org/ Fixes: ac338acf514e ("driver core: Add dev_has_sync_state()") Reviewed-by: Rafael J. Wysocki (Intel) Acked-by: Greg Kroah-Hartman Reviewed-by: Saravana Kannan Link: https://patch.msgid.link/20260418162221.1121873-1-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit cb6311f25a096621ac7ffd91b50d1bb1cfb63a96 Author: Srinivasan Shanmugam Date: Thu Apr 23 18:29:46 2026 +0530 drm/amdkfd: Validate CRIU-restored IDs before idr_alloc [ Upstream commit 85043dd49c2f51a37b22618168e3ae59ab92f0d6 ] The KFD CRIU restore flow restores previously saved object IDs from userspace. For event restore: kfd_criu_restore_event() -> create_signal_event() / create_other_event() -> allocate_event_notification_slot() -> idr_alloc(..., *restore_id, *restore_id + 1, ...) For BO restore: criu_restore_memory_of_gpu() -> idr_alloc(..., bo_priv->idr_handle, ...) In both cases, the restored ID comes from userspace-provided CRIU data. idr_alloc() expects the ID range values to fit within signed int limits. If a restored ID is larger than INT_MAX, it can trigger a WARN in the IDR layer. A kernel WARN is undesirable because it prints a warning trace and may cause a panic or reboot on systems with panic_on_warn enabled. Smatch reported these paths as allowing unchecked userspace values to reach idr_alloc(). Add INT_MAX validation before using restored IDs in: - kfd_criu_restore_event() - criu_restore_memory_of_gpu() If the restored ID is invalid, return -EINVAL. This prevents invalid restore data from reaching the IDR layer and avoids WARN-triggering paths, while keeping valid restore behavior unchanged. Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events") Reported-by: Dan Carpenter Cc: Felix Kuehling Cc: David Yat Sin Cc: Rajneesh Bhardwaj Signed-off-by: Srinivasan Shanmugam Reviewed-by: David Yat Sin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ff77834b70c0144862412506b87abeadc51d2313 Author: Felix Gu Date: Mon Apr 20 18:55:55 2026 +0800 pinctrl: pinconf-generic: fix properties bitmap leak in parse_fw_cfg() [ Upstream commit 352f5621b8c472bf328f452446bce85c00837223 ] In parse_fw_cfg(), if fwnode_property_match_property_string() fails with -ENOENT, the code returns directly and leaks the bitmap. Use __free(bitmap) for automatic cleanup to fix the leak. Fixes: 9c105255108b ("pinctrl: pinconf-generic: perform basic checks on pincfg properties") Signed-off-by: Felix Gu Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c6cb2aa31fc246ee548acfec470b8b48749e900a Author: Krzysztof Kozlowski Date: Fri Apr 10 13:10:48 2026 +0200 dt-bindings: pinctrl: nvidia,tegra234: Add missing required block [ Upstream commit 61b5deb5a968f7a82124f9b2591a6a151ed7273a ] Binding should require 'reg' property, because address space cannot be missing in the hardware and is already needed by the Linux drivers. Require also 'compatible' by convention, although it is not strictly necessary. Fixes: 857982138b79 ("dt-bindings: pinctrl: Document Tegra234 pin controllers") Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring (Arm) Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4e7d9b05bf64cdaced78a299f69ac2fe05dc37e2 Author: Jon Hunter Date: Wed Apr 1 11:29:41 2026 +0100 arm64: tegra: Fix Tegra234 MGBE PTP clock [ Upstream commit 8f0cc929a4bad534c5a860a53d88912cf16d9c9c ] The Tegra MGBE PTP clock is incorrectly named as 'ptp-ref' and not 'ptp_ref' and this causing the initialisation of the PTP clock to fail. The device-tree binding doc for the device and the Tegra MGBE driver have been updated to use the correct name and so update the device-tree for Tegra234 as well. Fixes: 610cdf3186bc ("arm64: tegra: Add MGBE nodes on Tegra234") Signed-off-by: Jon Hunter Reviewed-by: Krzysztof Kozlowski Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit d707dd37c6dcc16bc3106c17d14e1f94faa2c898 Author: Louis Kotze Date: Tue Apr 14 14:27:28 2026 +0200 wifi: cfg80211: fix grammar in MLO group key error message [ Upstream commit 9dcc1af3bbf5441f71a1e51b8d81bdf38a249607 ] The error message emitted by nl80211_validate_key_link_id() when a group key install on an MLO wdev is missing the link ID reads "link ID must for MLO group key", which is missing the words "be set". This makes the error harder to grep and parse in userspace logs, and is reported verbatim by wpa_supplicant via its nl80211 extack relay, e.g.: wpa_supplicant: nl80211: kernel reports: link ID must for MLO group key The sibling error strings in the same helper already use grammatical phrasing ("link ID not allowed for pairwise key", "invalid link ID for MLO group key", "link ID not allowed for non-MLO group key"). Fix this one to match. No functional change. Fixes: e7a7b84e3317 ("wifi: cfg80211: Add link_id parameter to various key operations for MLO") Signed-off-by: Louis Kotze Link: https://patch.msgid.link/20260414122728.92234-1-loukot@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 306265eb9384d2c224f1b14d83a29323f0eab6d1 Author: Edward Adam Davis Date: Fri Apr 17 07:44:02 2026 +0800 hfsplus: Add a sanity check for btree node size [ Upstream commit 3f95e2661574ff13f099dd13456751933c280628 ] Syzbot reported an uninit-value bug in [1] with a corrupted HFS+ image, during the file system mounting process, specifically while loading the catalog, a corrupted node_size value of 1 caused the rec_off argument passed to hfs_bnode_read_u16() (within hfs_bnode_find()) to be excessively large. Consequently, the function failed to return a valid value to initialize the off variable, triggering the bug [1]. Every node starts from BTree node descriptor: struct hfs_bnode_desc. So, the size of node cannot be lesser than that. However, technical specification declares that: "The node size (which is expressed in bytes) must be power of two, from 512 through 32,768, inclusive." Add a check for btree node size base on technical specification. [1] BUG: KMSAN: uninit-value in hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584 hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584 hfsplus_btree_open+0x169a/0x1e40 fs/hfsplus/btree.c:382 hfsplus_fill_super+0x111f/0x2770 fs/hfsplus/super.c:553 get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694 get_tree_bdev+0x38/0x50 fs/super.c:1717 hfsplus_get_tree+0x35/0x40 fs/hfsplus/super.c:709 vfs_get_tree+0xb3/0x5d0 fs/super.c:1754 fc_mount fs/namespace.c:1193 [inline] Fixes: 8ad2c6a36ac4 ("hfsplus: validate b-tree node 0 bitmap at mount time") Reported-by: syzbot+217eb327242d08197efb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=217eb327242d08197efb Signed-off-by: Edward Adam Davis Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/tencent_5ED373437A697F83A4A446B771577626CD05@qq.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit b3c7ccb1a93cbb5a9a13196abf608ffa2516817e Author: Edward Adam Davis Date: Thu Apr 16 11:37:53 2026 +0800 hfsplus: Remove the duplicate attr inode dirty marking action [ Upstream commit 7a41fd2b32e5908f19a68732008d581c167279dd ] Syzbot reported a null-ptr-deref in [1]. If the attributes file is not loaded during system mount, a trigger occurs [1] when setxattr is executed in userspace. Remove the first mark attr inode dirty operation. [1] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Call Trace: hfsplus_setxattr+0x124/0x340 fs/hfsplus/xattr.c:555 hfsplus_trusted_setxattr+0x40/0x60 fs/hfsplus/xattr_trusted.c:30 __vfs_setxattr+0x43c/0x480 fs/xattr.c:218 __vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:252 vfs_setxattr+0x163/0x360 fs/xattr.c:339 do_setxattr fs/xattr.c:654 [inline] Reported-by: syzbot+bc70a12e438dadba4fb4@syzkaller.appspotmail.com Fixes: ee8422d00b7c ("hfsplus: fix potential Allocation File corruption after fsync") Closes: https://syzkaller.appspot.com/bug?extid=bc70a12e438dadba4fb4 Signed-off-by: Edward Adam Davis Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/tencent_A8D47429765566CC3C8B378496D036664A09@qq.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2c112ae55546ff240c2bcf097a1208c88cb4b8d2 Author: David Heidelberg Date: Fri Apr 3 15:58:48 2026 +0200 arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state [ Upstream commit 0689aa70fe28ba13eb1d8b10d50e08157ade9670 ] There is no suspend state in the mainline kernel, use the sleep state intended for this purpose. Fixes: 45882459159d ("arm64: dts: qcom: sdm845: add device tree for SHIFT6mq") Signed-off-by: David Heidelberg Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260403-oneplus-nfc-v3-3-fbdce57d63c1@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c72381bc70f545ab09f94cb4dcbe50cc19a49bf6 Author: Kamal Wadhwa Date: Mon Apr 6 19:05:55 2026 +0530 arm64: dts: qcom: fix temp-alarm probe failure for PMH0104 on Glymur [ Upstream commit e8fae9152e100b4bb30d38b25bc9c81623e8e91e ] The temp-alarm driver probe is failing for the pmh0104 PMICs on glymur. [ 3.999713] spmi-temp-alarm c426000.spmi:pmic@8:temp-alarm@a00: error -ENODEV: failed to register sensor [ 4.015066] spmi-temp-alarm c426000.spmi:pmic@9:temp-alarm@a00: error -ENODEV: failed to register sensor [ 4.033908] spmi-temp-alarm c437000.spmi:pmic@b:temp-alarm@a00: error -ENODEV: failed to register sensor This happens because thermal zone associated with the temp alarm was defined under the thermal zones parent node which had a typo (used `_` in place of `-`). Correct the typo to fix probe failure. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Kamal Wadhwa Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260406-glymur-pmh0104-temp-alarm-fix-v1-1-4441b7b01f85@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0ca70d4382981bb7079352647b09978968b16b33 Author: Krzysztof Kozlowski Date: Sun Apr 5 15:39:32 2026 +0200 arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg warning [ Upstream commit f20a82aacd7f381084391a8d1f0f58defa91974c ] Add necessary properties for ports node in SDM845 DB845c Navigation mezzanine overlay to fix W=1 DTC warning: sdm845-db845c-navigation-mezzanine.dtso:19.10-24.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property Fixes: 30df676a31b7 ("arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: Convert mezzanine riser to dtso") Reviewed-by: Dmitry Baryshkov Reviewed-by: David Heidelberg Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260405-dts-qcom-w-1-fixes-v2-5-1f2c7b74a93f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1d066a4d678d2018b34790826329db8f8201d666 Author: Krzysztof Kozlowski Date: Sun Apr 5 15:39:31 2026 +0200 arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning [ Upstream commit f319a5fc998e29699d325af0e461721b3768eeec ] Correct the unit address of phy node in Qualcomm SC8180x SoC DTSI to fix W=1 DTC warning: sc8180x.dtsi:2650.31-2695.5: Warning (simple_bus_reg): /soc@0/phy@88ee000: simple-bus unit address format error, expected "88ed000" Fixes: 35e3a9c1afce ("arm64: dts: qcom: sc8180x: switch USB+DP QMP PHYs to new bindings") Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260405-dts-qcom-w-1-fixes-v2-4-1f2c7b74a93f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4b47923d5310bb43ccde57dff2507340210c1a15 Author: Krzysztof Kozlowski Date: Sun Apr 5 15:39:30 2026 +0200 arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings [ Upstream commit 864fde494aa1dd26c68254661f2ce973e9f03832 ] Correct the unit address of USB nodes in Qualcomm IPQ5424 SoC DTSI to fix W=1 DTC warnings: ipq5424.dtsi:642.22-693.5: Warning (simple_bus_reg): /soc@0/usb2@1e00000: simple-bus unit address format error, expected "1ef8800" ipq5424.dtsi:733.22-786.5: Warning (simple_bus_reg): /soc@0/usb3@8a00000: simple-bus unit address format error, expected "8af8800" Fixes: 113d52bdc820 ("arm64: dts: qcom: ipq5424: Add USB controller and phy nodes") Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260405-dts-qcom-w-1-fixes-v2-3-1f2c7b74a93f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 92b4e73fd38136c1cfbf3920d0456015ebf65136 Author: Krzysztof Kozlowski Date: Sun Apr 5 15:39:29 2026 +0200 arm64: dts: qcom: glymur: Fix cache and SRAM simple_bus_reg warnings [ Upstream commit 46eccc1034c3740b07b58c125190bbb99247c9de ] Correct the unit address of cache controller and SRAM nodes in Qualcomm Glymur SoC DTSI to fix W=1 DTC warnings: glymur.dtsi:5876.36-5908.5: Warning (simple_bus_reg): /soc@0/system-cache-controller@20400000: simple-bus unit address format error, expected "21800000" glymur.dtsi:5917.23-5934.5: Warning (simple_bus_reg): /soc@0/sram@81e08000: simple-bus unit address format error, expected "81e08600" Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260405-dts-qcom-w-1-fixes-v2-2-1f2c7b74a93f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 460e2fb9f8da6754b40948a9bfed4ebf30d78b4e Author: Krzysztof Kozlowski Date: Sun Apr 5 15:39:28 2026 +0200 arm64: dts: qcom: glymur: Fix USB simple_bus_reg warning [ Upstream commit cd66b6d256f94e40922941e14d7f9390d35d072b ] Correct the unit address of USB node in Qualcomm Glymur SoC DTSI to fix W=1 DTC warning: glymur.dtsi:4027.23-4093.5: Warning (simple_bus_reg): /soc@0/usb@a2f8800: simple-bus unit address format error, expected "a200000" Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes") Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260405-dts-qcom-w-1-fixes-v2-1-1f2c7b74a93f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit be1d8901ac74cab7bfc3e39e638b36850cc412a6 Author: David Heidelberg Date: Thu Apr 2 00:39:36 2026 +0200 arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node [ Upstream commit b379bb1470d864659ae9522b72f241a15255dce6 ] This node has no 'reg' property, so it shouldn't have a unit address (after '@') either Fixes: b0d5c96e860c ("arm64: dts: qcom: sdm845-oneplus: Add framebuffer") Reviewed-by: Dmitry Baryshkov Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20260402-beryllium-fb-v4-2-46170004da28@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2a51c2954ac6a0678c6ae03b2b69c40b2b3cf937 Author: Alexander Koskovich Date: Mon Mar 23 13:54:42 2026 +0000 arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB [ Upstream commit 1f820571ca7c64d3fd5bd9bf653b571cb3350703 ] The rmtfs_mem region is currently sized at 6MiB but the default for milos downstream is 2.5MiB. This causes remoteproc crashes on devices that expect the smaller size: modem_ac.c:281:Access Control Error: Could not protect the region specified:Start:e1f00000 End:e2180000, PID:1 Reduce the default to 2.5MiB to match the QCOM downstream config, and override the size for FP6. Fixes: d9d59d105f98 ("arm64: dts: qcom: Add initial Milos dtsi") Reviewed-by: Luca Weiss Reviewed-by: Konrad Dybcio Signed-off-by: Alexander Koskovich Link: https://lore.kernel.org/r/20260323-asteroids-v2-1-1a35fa9e178a@pm.me Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f0dbf9e5d82e87b4fd2500ed934504778d2db4fa Author: Sean Christopherson Date: Thu Apr 23 07:54:17 2026 -0700 x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs [ Upstream commit 40c4b47f41b95dff743c841536cb64014e65ef0c ] Add explicit printf() validation for x86-64's newfangled WARN implementation, as most (all?) compilers fail to detect basic formatting issues without the annotation. E.g. even goofs like printing a u64 as a string aren't detected: WARN_ONCE(1, "Bad message, %s", vcpu->arch.last_guest_tsc); 32-bit x86 doesn't support HAVE_ARCH_BUG_FORMAT_ARGS and uses generic implementations that provide printf() validation. This means there's now a big blind spot is code that is strictly x86-64. Inconveniently, new features are also frequently x86-64-only. Fix the blind 64-bit blind spot. [ dhansen: changelog tweaks to flesh out the 64-bit-only details ] Fixes: 5b472b6e5bd9 ("x86_64/bug: Implement __WARN_printf()") Fixes: 11bb4944f014 ("x86/bug: Implement WARN_ONCE()") Signed-off-by: Sean Christopherson Signed-off-by: Dave Hansen Acked-by: Dave Hansen Link: https://lore.kernel.org/all/adc1IrD8uqWdaOKv@yzhao56-desk.sh.intel.com Link: https://patch.msgid.link/20260423145419.459988-2-seanjc@google.com Signed-off-by: Sasha Levin commit dc0f024484b0875266f8ffdbf346db948627a80f Author: Konrad Dybcio Date: Wed Feb 25 13:23:21 2026 +0100 dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names [ Upstream commit 63b35a29d7ad2cafb0076f8b002b30fb74df053a ] Commit 5f4f954bba12 ("dt-bindings: bluetooth: bring the HW description closer to reality for wcn6855") changed the vddrfa1p7-supply to 1p8 for whatever reason. The schematics footprint for this chip definitely says 7 on the input leg and the driver still expects 1p7. Bring it back. Fixes: 5f4f954bba12 ("dt-bindings: bluetooth: bring the HW description closer to reality for wcn6855") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Abel Vesa Reviewed-by: Bartosz Golaszewski Acked-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260225-topic-wcn6855_pmu_dtbdings-v3-1-576ec5c4e631@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 342828cf47812e5d95afa1c36c06523155ccf624 Author: Kamlesh Kumar Date: Fri Apr 24 17:09:46 2026 +0530 ima: Fix sigv3 signature handling for EVM_IMA_XATTR_DIGSIG [ Upstream commit 398ee113f15c1e8e62535e54f22fb4db340c7835 ] ima_get_hash_algo() only recognizes version 2 signatures when the xattr type is EVM_IMA_XATTR_DIGSIG. Since sigv3 signatures also use EVM_IMA_XATTR_DIGSIG as the xattr type, version 3 must be accepted as well to correctly determine the hash algorithm. Additionally, ima_validate_rule() does not include IMA_SIGV3_REQUIRED in the allowed flags bitmask for MODULE_CHECK, KEXEC_KERNEL_CHECK, and KEXEC_INITRAMFS_CHECK hook functions. As a result, policy rules with "appraise_type=sigv3" are rejected for these functions. Add version 3 to the accepted versions in ima_get_hash_algo() for EVM_IMA_XATTR_DIGSIG, and add IMA_SIGV3_REQUIRED to the allowed flags for MODULE_CHECK, KEXEC_KERNEL_CHECK, and KEXEC_INITRAMFS_CHECK in ima_validate_rule(). Signed-off-by: Kamlesh Kumar Tested-by: Stefan Berger Fixes: de4c44a7f559 ("ima: add support to require IMA sigv3 signatures") Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit aaea3af1fbf1bebd056d81a58cbcabe98154f9dc Author: Diederik de Haas Date: Wed Apr 1 15:11:38 2026 +0200 arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S [ Upstream commit c83c4a09d4c01c91d6c52d6d4d77a06892a3e83b ] According to the NanoPi R5S 2204 schematic on page 6, GPIO0_C4 is for GMAC0_INT/PMEB_GPIO0_C4, while GPIO0_C5 is for GMAC0_RSTn_GPIO0_C5. While the 'reset-gpios' property was set correctly, the corresponding pinctrl didn't match that. Next to fixing the pinctrl definition, also change the node name and phandle to match what is used in the schematic. Fixes: c6629b9a6738 ("arm64: dts: rockchip: Add FriendlyElec Nanopi R5S") Signed-off-by: Diederik de Haas Link: https://patch.msgid.link/20260401131551.734456-2-diederik@cknow-tech.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit f63a5ae90d614917591cb4f09e85a0871e2b5b1f Author: Quentin Schulz Date: Tue Apr 21 11:45:05 2026 +0200 arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra [ Upstream commit 6598ed3586a4b1cc79423666e66b9861631a6c7e ] When not passing the PHY ID with an ethernet-phy-idX.Y compatible property, the MDIO bus will attempt to auto-detect the PHY by reading its registers and then probing the appropriate driver. For this to work, the PHY needs to be in a working state. Unfortunately, the net subsystem doesn't control the PHY reset GPIO when attempting to auto-detect the PHY. This means the PHY needs to be in a working state when entering the Linux kernel. This historically has been the case for this device, but only because the bootloader was taking care of initializing the Ethernet controller even when not using it. We're attempting to support the removal of the network stack in the bootloader, which means the Linux kernel will be entered with the PHY still in reset and now Ethernet doesn't work anymore. The devices in the field only ever had a TI DP83825, so let's simply bypass the auto-detection mechanism entirely by passing the appropriate PHY IDs via the compatible. Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants") Signed-off-by: Quentin Schulz Link: https://patch.msgid.link/20260421-px30-eth-phy-v2-1-68c375b120fd@cherry.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d07a6ee87fd995f8f4d54d182ff05e50e2d4cb57 Author: Cristian Ciocaltea Date: Wed Mar 4 23:00:43 2026 +0200 arm64: dts: rockchip: Update vdec register blocks order on RK3588 [ Upstream commit b481c11cd20a114c4df35f3b1ecd28b05e622067 ] With the introduction of the RK3588 SoC, three register blocks have been provided for the video decoder unit instead of just one, which are further referenced in the vendor's datasheet by 'link table', 'function' and 'cache'. The former is present at the top of the listing, starting at video decoder unit base address, but the binding got this wrong initially, i.e. the 'function' block got listed before the 'link' one. Since the video decoder support for the aforementioned SoC in mainline driver and devicetrees hasn't been released yet (just landed in v7.0-rc1), address the problem by providing the register blocks for vdec0 & vdec1 nodes using the 'link,function,cache' listing, which ensures the unit address points to the primary register range. This aligns with a similar fix for RK3576, where DTC also complained about the bus address format. Fixes: f61731bd6062 ("arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260304-vdec-reg-order-rk3576-v5-4-7006fad42c3a@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d4275810ed6a95454fc74fccf65ee50c6dd7ecfa Author: Cristian Ciocaltea Date: Wed Mar 4 23:00:42 2026 +0200 arm64: dts: rockchip: Fix vdec register blocks order on RK3576 [ Upstream commit 63fd2f6aa402a105fa22ede6f3c35dafd64827a5 ] When building device trees for the RK3576 based boards, DTC shows the following complaint: rk3576.dtsi:1282.30-1304.5: Warning (simple_bus_reg): /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100" Since the video decoder support for the aforementioned SoC in mainline driver and devicetrees hasn't been released yet (just landed in v7.0-rc1), fix the issue by providing the register blocks using the 'link,function,cache' listing, which follows the address-based order as shown in the vendor's datasheet and, implicitly, ensures the unit address points to the primary register range. Fixes: da0de806d8b4 ("arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260304-vdec-reg-order-rk3576-v5-3-7006fad42c3a@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 342db93e484471216a960b24dc66723fd7003614 Author: Baolin Liu Date: Fri Apr 24 17:06:54 2026 +0800 Documentation: proc: fix section numbering in table of contents [ Upstream commit 97a7bd8c2c58a6d820df563d1d0f68aafec45477 ] Commit e24ccaaf7ec4 ("block: remove last remaining traces of IDE documentation") removed the IDE section but left its table of contents entry behind. Fix the stale entry and renumber the following sections. Fixes: e24ccaaf7ec4 ("block: remove last remaining traces of IDE documentation") Signed-off-by: Baolin Liu Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260424090654.19229-1-liubaolin12138@163.com> Signed-off-by: Sasha Levin commit 313849b13e054b60abc43095f48d2cf1cdf1df2d Author: Gregory Bell Date: Fri Apr 17 11:41:22 2026 -0400 selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern [ Upstream commit afb0450be061907a0f5d36bd8b010ca30eda3d3b ] Replace the forward-declared struct bpf_fou_encap with the existing bpf_fou_encap___local type in the bpf_skb_set_fou_encap and bpf_skb_get_fou_encap declarations. This removes the need for the forward declaration and the explicit casts at each call. Fixes: d17f9b370df6 ("selftests/bpf: Fix compilation failure when CONFIG_NET_FOU!=y") Signed-off-by: Gregory Bell Link: https://lore.kernel.org/r/20260417154122.2558890-3-grbell@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e93b36361458258b87e7c458d5628cff53bf39ca Author: Gregory Bell Date: Fri Apr 17 11:41:21 2026 -0400 selftests/bpf: Use local type for flow_offload_tuple_rhash in xdp_flowtable [ Upstream commit ac985e7bf840e34a8dafe0808cc571fd85896c30 ] Define flow_offload_tuple_rhash___local and use it in place of the forward-declared kernel type for the bpf_xdp_flow_lookup kfunc return type and tuplehash variable. This is consistent with how bpf_flowtable_opts___local is already handled in the same file and avoids relying on a forward declaration of the struct. Fixes: eeb23b54e447 ("selftests/bpf: fix compilation failure when CONFIG_NF_FLOW_TABLE=m") Signed-off-by: Gregory Bell Link: https://lore.kernel.org/r/20260417154122.2558890-2-grbell@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit af6a34c41683067a314d2b58b39edecb2e5e4ac6 Author: Felix Gu Date: Fri Apr 17 00:27:54 2026 +0800 spi: atcspi200: fix use-after-free when driver unbind [ Upstream commit 565bdf45125a05aa8f622f58f598283f46ba43f4 ] DMA resource is initialized after SPI controller registration. So when driver unbind, this can trigger a use-after-free when DMA is torn down while the controller is still alive and triggers DMA transfers. Fixes: 34e3815ea459 ("spi: atcspi200: Add ATCSPI200 SPI controller driver") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260417-atcspi-v1-1-854831667d63@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a59eb502641a6f792ac7d261a93bc718554d548a Author: Yang Wang Date: Tue Mar 17 20:58:07 2026 -0400 drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro [ Upstream commit 0d892afb52d2b940d891b6b52dc9f04debef2d81 ] macros should not include a trailing semicolon as per kernel coding style (checkpatch.pl warning). move the semicolon from the macro definition to the invocation sites instead. checkpatch.pl logs: WARNING: macros should not use a trailing semicolon +#define AMDGPU_PM_POLICY_ATTR(_name, _id) \ + static struct amdgpu_pm_policy_attr pm_policy_attr_##_name = { \ + .dev_attr = __ATTR(_name, 0644, amdgpu_get_pm_policy_attr, \ + amdgpu_set_pm_policy_attr), \ + .id = PP_PM_POLICY_##_id, \ + }; Fixes: 4d154b1ca580 ("drm/amd/pm: Add support for DPM policies") Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5da57e99987bc9f96150e872cc49d6ca31159541 Author: Antoine Tenart Date: Fri Apr 17 10:33:17 2026 +0200 libbpf: Fix deduplication of typedef with base definitions [ Upstream commit 0831b110eb4591e4ad8c5fd0d8f0f3f9979a5ff5 ] When deduplicating definitions for a module, typedef defined in the base are not removed. This is because the hash used for base types differs from the one used in the deduplication logic in btf_dedup_struct_type. This was introduced by the referenced commit when moving the typedef deduplication logic handling from btf_dedup_ref_type to btf_dedup_struct_type, as this also changed the hash logic (btf_hash_common to btf_hash_typedef). This also impacts other types referencing those typedef (e.g. const). In my test, the BTF section size of the openvswitch module went from 31KB to 45KB. Fixes: 3781413465df ("libbpf: Fix BTF dedup to support recursive typedef definitions"). Signed-off-by: Antoine Tenart Signed-off-by: Andrii Nakryiko Tested-by: Alan Maguire Reviewed-by: Alan Maguire Link: https://lore.kernel.org/bpf/20260417083319.32716-1-atenart@kernel.org Signed-off-by: Sasha Levin commit 585f673e728516088dcf768f24a121789ae97227 Author: Aaradhana Sahu Date: Tue Apr 14 11:58:29 2026 +0530 wifi: ath12k: Fix invalid IRQ requests during AHB probe [ Upstream commit 590182b72213ef04977ab0b16b8dadfcfd25ff73 ] ath12k_ahb_config_ext_irq() iterates over ATH12K_EXT_IRQ_NUM_MAX (16) entries while checking TX ring masks, but the tcl_to_wbm_rbm_map array contains only DP_TCL_NUM_RING_MAX (4) valid elements. When the iterator (j) is greater than or equal to DP_TCL_NUM_RING_MAX, it accesses tcl_to_wbm_rbm_map[j] out of bounds. This results in reading uninitialized memory for wbm_ring_num, causing the driver to evaluate incorrect BIT() conditions and request IRQs for rings that do not have an assigned interrupt line or device tree entry. This leads to request_irq() failures with -ENXIO or -EINVAL during ath12k AHB probe. Fix this by splitting the loop into two separate loops: one iterating over DP_TCL_NUM_RING_MAX for TX ring, and another iterating over ATH12K_EXT_IRQ_NUM_MAX for remaining IRQ entries. Also add a bounds check for num_irq. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Fixes: 6cee30f0da75 ("wifi: ath12k: add AHB driver support for IPQ5332") Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260414062829.2371761-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit eb99b69b743ee8aeb4017e0689ea2e049120ebf4 Author: Nick Hu Date: Sun Apr 19 23:18:55 2026 -0700 dt-bindings: timer: Remove sifive,fine-ctr-bits property [ Upstream commit 1ccca10755107bc8c649937d1ba69651d1ef9da2 ] The counter width can be inferred from the compatible string, making the explicit "sifive,fine-ctr-bits" property redundant. Remove the property to simplify the bindings. Fixes: 0f920690a82c ("dt-bindings: timer: Add SiFive CLINT2") Suggested-by: Conor Dooley Signed-off-by: Nick Hu Signed-off-by: Daniel Lezcano Acked-by: Conor Dooley Link: https://lore.kernel.org/linux-riscv/20260330-relative-hardened-5ce35fe1ef57@spud/ Link: https://patch.msgid.link/20260419-clintv2-remove-fine-ctr-v1-1-7527f4d45850@sifive.com Signed-off-by: Sasha Levin commit 0ac0063afc55c8e4a56b7b415b5e8030295d6432 Author: Matt Bobrowski Date: Mon Apr 20 09:37:34 2026 +0000 selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest [ Upstream commit 0aa6378695b8c67146130812f635f07c4898f171 ] The test_populate test uses >= instead of > when checking if the runtime nr_cpus exceeds the bit capacity of a cpumask_t. On a system where the physical CPU core count perfectly matches the CONFIG_NR_CPUS upper bound (e.g. nr_cpus = 512 and CONFIG_NR_CPUS = 512), the condition nr_cpus >= CPUMASK_TEST_MASKLEN * 8 evaluates to true (512 >= 512). This incorrectly causes the test to fail with an error value of 3. A 512-bit cpumask_t provides enough bits (indices 0 through 511) to represent 512 CPUs. The subsequent bpf_for(i, 0, nr_cpus) loop iterates up to nr_cpus - 1 (511), which perfectly aligns with the maximum valid index of the bitmask. Change the condition to nr_cpus > CPUMASK_TEST_MASKLEN * 8 to fix the false positive failure on these systems. Fixes: 918ba2636d4e ("selftests: bpf: add bpf_cpumask_populate selftests") Signed-off-by: Matt Bobrowski Acked-by: Paul Chaignon Link: https://lore.kernel.org/bpf/20260420093734.2400330-1-mattbobrowski@google.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit c521733289b7cb12a0fd2d6e59ca0aea9bfecad8 Author: Aaron Tomlin Date: Sat Apr 18 23:09:44 2026 -0400 libbpf: Report error when a negative kprobe offset is specified [ Upstream commit ad35d8018669fd2eea76e3f74eb050fd3d2fb690 ] In attach_kprobe(), the parsing logic uses sscanf() to extract the target function name and offset from the section definition. Currently, if a user specifies a negative offset (e.g., SEC("kprobe/func+-100")), the input is not explicitly caught and reported as an error. This commit updates the logic to explicitly notify the user when a negative integer is provided. To facilitate this check, the offset variable is changed from unsigned long to long so that sscanf() can accurately capture a negative input for evaluation. If a negative offset is detected, the loader will now print an informative warning stating that the offset must be non-negative, and return -EINVAL. Additionally, free(func) is called in this new error path to prevent a memory leak, as the function name string is dynamically allocated by sscanf(). Fixes: e3f9bc35ea7e9 ("libbpf: Allow decimal offset for kprobes") Signed-off-by: Aaron Tomlin Acked-by: Mykyta Yatsenko Link: https://lore.kernel.org/bpf/20260419030944.1423642-1-atomlin@atomlin.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit ccc42187fc2d0720947a63ce1b9e399d2c068ff4 Author: Yuho Choi Date: Thu Apr 16 15:55:37 2026 -0400 drm/radeon: fix memory leak in radeon_ring_restore() on lock failure [ Upstream commit 82f1d6042611d45b8b9de423bbcb4e0ced9ec62b ] radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error. Fixes: 55d7c22192be ("drm/radeon: implement ring saving on reset v4") Signed-off-by: Yuho Choi Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dfc7b5b5599472277e71e5bd2712740651c7c5be Author: Werner Kasselman Date: Wed Apr 15 22:13:52 2026 +0000 drm/radeon: fix integer overflow in radeon_align_pitch() [ Upstream commit ce3b24eb3ee8f82de851535f516bf21f83e82259 ] radeon_align_pitch() has the same kind of overflow issue as the old amdgpu helper: both the alignment round-up add and the final 'aligned * cpp' calculation can overflow signed int. If that wraps, radeon_mode_dumb_create() can end up returning an invalid pitch or creating a zero-sized dumb buffer. Fix this by using check_add_overflow() for the alignment round-up and check_mul_overflow() for the final pitch calculation, returning 0 on overflow. Also reject zero pitch and size in radeon_mode_dumb_create(). Found via AST-based call-graph analysis using sqry. Fixes: ff72145badb8 ("drm: dumb scanout create/mmap for intel/radeon (v3)") Signed-off-by: Werner Kasselman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4bab3a7e66db9b6311586c4178e68eabbb15b29e Author: Alex Sierra Date: Tue Apr 7 17:22:44 2026 -0500 drm/amdkfd: fix redundant MQD iterations in GFX v12.1 [ Upstream commit 9315a1e2bdf1ba4aace856cabcb5f9f3a5c09202 ] The init_mqd_v12_1 function and its sub-call update_mqd_v12_1 both independently iterate over XCC-specific MQDs. This nested iteration is redundant and can cause MQDs in different queues to be overwritten. This patch removes the duplicate loop logic to prevent queue corruption. Fixes: 01bbc4a4b947 ("drm/amdkfd: Add MQD manager for GFX 12.1.0") Signed-off-by: Alex Sierra Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 50d468733e5ec9ed3ec1ecfce6b4c7c312630412 Author: Werner Kasselman Date: Tue Apr 14 05:08:42 2026 +0000 drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch() [ Upstream commit fc3659f178d4a65599167d5a648bbeef4b0d4446 ] amdgpu_gem_align_pitch() is passed u32 width and cpp from dumb buffer creation but uses signed int internally. The round-up add and the aligned * cpp multiplication can overflow, returning zero or a negative pitch. A zero pitch propagates to a zero-sized GEM object allocation that reaches userspace via DRM_IOCTL_MODE_CREATE_DUMB. Switch the helper to unsigned int and use check_add_overflow() / check_mul_overflow() so wraparound returns zero. Reject a zero pitch or size in amdgpu_mode_dumb_create() rather than allocating a zero- byte BO. Fixes: 8e911ab770f7 ("drm: amdgpu: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()") Signed-off-by: Werner Kasselman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 83d6d375f357ed2702b28d739511aad56d485de7 Author: Max Zhen Date: Thu Apr 16 13:11:06 2026 -0700 accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer [ Upstream commit 506255d46bdb93a281cf39e72abbca124f5c7a1b ] The management mailbox channel cleanup helpers can be called from error handling paths when mgmt_chann has already been destroyed. Add NULL checks to xdna_mailbox_free_channel() and xdna_mailbox_stop_channel() so the cleanup path safely returns instead of dereferencing a NULL mailbox channel pointer. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260416201106.1046072-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 3a555d9e92d598948a8e8bef5996b242b9743a99 Author: Jonathan Cavitt Date: Fri Jan 30 19:19:54 2026 +0000 drm/gpuvm: Do not prepare NULL objects [ Upstream commit 88f059f6f6f589bd78e2ceb05a1339a8c10b8626 ] Statis analysis issue: drm_gpuvm_prepare_range issues an exec_object_prepare call to all drm_gem_objects mapped between addr and addr + range. However, it is possible (albeit very unlikely) that the objects found through drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer. Do not prepare NULL objects. Fixes: 50c1a36f594b ("drm/gpuvm: track/lock/validate external/evicted objects") Signed-off-by: Jonathan Cavitt Cc: Matthew Brost Cc: Thomas Hellström Reviewed-by: Krzysztof Karas Link: https://patch.msgid.link/20260130191953.61718-2-jonathan.cavitt@intel.com Signed-off-by: Sasha Levin commit 966e13ccadc87e3010285a80f80c99d4259e47ea Author: Felix Gu Date: Thu Apr 16 21:37:23 2026 +0800 accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc() [ Upstream commit 432fafdc9a3122a7bee5b2bfd23dcf2dc262a3d7 ] In amdxdna_iommu_alloc(), if iommu_map() fails after successfully allocating both iova and cpu_addr, the code jumps to free_iova which only frees the iova, leaking the allocated pages. Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Signed-off-by: Felix Gu Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260416-amdxdna-v1-1-30c13008365c@gmail.com Signed-off-by: Sasha Levin commit 6ddaf49a1088f7bd7eef278d7fcb3a2eceb4b458 Author: Max Zhen Date: Tue Apr 14 09:56:24 2026 -0700 accel/amdxdna: Fix fatal_error_info layout in firmware interface [ Upstream commit 2d1e82f1224f3109481bb0ed3683e54b09b978e3 ] Adjust struct fatal_error_info to match the expected driver/firmware interface layout. The structure is used to retrieve debug information from firmware when a command becomes stuck on the device. The reserved field currently uses 128 u32 entries, which makes the structure larger than intended and causes the layout to no longer match the firmware definition. Reduce the reserved array size from 128 to 127 entries so the structure matches the expected interface format. Fixes: 25854131c04a ("accel/amdxdna: Support retrieving hardware context debug information") Signed-off-by: Max Zhen Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260414165625.788853-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 4e01fc9a5bc49b04fad403ffa71299b35e132ca8 Author: Tvrtko Ursulin Date: Wed Apr 15 09:32:07 2026 +0100 dma-fence: Fix potential tracepoint null pointer dereferences [ Upstream commit e94b9f01543cc6a83538c2c2cc645a424d3015ca ] Trace_dma_fence_signaled, trace_dma_fence_wait_end and trace_dma_fence_destroy can all currently dereference a null fence->ops pointer after it has been reset on fence signalling. Lets use the safe string getters for most tracepoints to avoid this class of a problem, while for the signal tracepoint we move it to before ops are cleared to avoid losing the driver and timeline name information. Apart from moving it we also need to add a new tracepoint class to bypass the safe name getters since the signaled bit is already set. For dma_fence_init we also need to use the new tracepoint class since the rcu read lock is not held there, and we can do the same for the enable signaling since there we are certain the fence cannot be signaled while we are holding the lock and have even validated the fence->ops. Signed-off-by: Tvrtko Ursulin Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Cc: Christian König Cc: Philipp Stanner Cc: Boris Brezillon Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260415083207.40513-2-tvrtko.ursulin@igalia.com Signed-off-by: Sasha Levin commit ebfc332033a46e3c35223909c5e4dde24f643945 Author: Lizhi Hou Date: Mon Apr 13 11:18:43 2026 -0700 accel/amdxdna: Fix order of canceled mailbox messages [ Upstream commit c83ad8ea6b0a53f1ed61ae0b4b9606bdfe338b33 ] Mailbox message IDs are allocated cyclically. When destroying a mailbox channel, pending messages are canceled starting from message ID 0. This results in an incorrect cancellation order when the ID of the last posted message wraps around and is smaller than the ID of the first posted message. Fix this by canceling pending messages starting from the next available message ID, ensuring the correct ordering across wraparound. Fixes: a37d78470bcc ("accel/amdxdna: Replace idr api with xarray") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260413181843.670796-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 032645be8d88ae575d84fbe6e56db67ae5ba9580 Author: Lizhi Hou Date: Mon Apr 13 11:02:38 2026 -0700 accel/amdxdna: Fix iommu_map_sgtable() return value handling [ Upstream commit 1bcfa4c4e88a554d1b6f98f4e3f886288581cbb4 ] iommu_map_sgtable() returns negative error codes on failure, but the result is stored in an unsigned variable. This prevents proper error detection. Change the variable type to ssize_t so negative error values can be handled correctly. Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/adk7kOUBwIyYnX1M@stanley.mountain/ Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Wendy Liang Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260413180238.668441-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit afc9ebbb0a9bb76c2becafb36804b3b2a5f2d751 Author: Max Zhen Date: Mon Apr 6 14:14:03 2026 -0700 accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path [ Upstream commit f844177c6811fd322aa84ed5c32f0e39743446c2 ] Route DETACH_DEBUG_BO through aie2_config_debug_bo() the same way as ATTACH_DEBUG_BO. The scheduler switch in aie2_sched_job_run() already handles ATTACH_DEBUG_BO with aie2_config_debug_bo(), but DETACH_DEBUG_BO was not included in that path. Add an explicit fallthrough so both attach and detach operations use the same handler. This fixes debug BO detach handling by ensuring the detach command is processed by the expected configuration path. Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Signed-off-by: Max Zhen Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260406211403.4011988-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 097e57195ef813735c8b714d6503bf3ad0742515 Author: Lizhi Hou Date: Thu Apr 2 10:41:48 2026 -0700 accel/amdxdna: Adjust size for copy_to_user() [ Upstream commit 6e87001fe19f251e2ae14373bc76554358a13df2 ] The amount of data returned to user space should be limited by the buffer size provided by the application. If the buffer is smaller than the data size, return only the portion that fits instead of failing. Fixes: 850d71f6bf4c ("accel/amdxdna: Add query functions") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260402174148.3527757-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 95a1c14bdf450e0cc5268ebe33332af5bb7ebcd6 Author: Lizhi Hou Date: Mon Mar 30 09:37:00 2026 -0700 accel/amdxdna: Create shared functions for AIE2 and AIE4 [ Upstream commit 5a55a5da1f01274c07359b09abec952ec9f05105 ] The AIE4 platform uses a mailbox management channel mechanism similar to AIE2 to communicate with the firmware. Create aie.h and aie.c and move the functions and structures that can be shared by both platforms from the AIE2-specific files into these common files. This allows AIE2 and AIE4 to reuse the same implementation and reduces code duplication. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260330163705.3153647-2-lizhi.hou@amd.com Stable-dep-of: 6e87001fe19f ("accel/amdxdna: Adjust size for copy_to_user()") Signed-off-by: Sasha Levin commit 63f443384979563f16f70420f4fa85bba31238ca Author: Matthew Brost Date: Wed Mar 25 16:16:08 2026 -0700 drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges [ Upstream commit b82a225e57a334335a21462b75ee2223bc6efe6d ] VMAs marked with VM_IO or VM_PFNMAP are not backed by struct page objects, which GPUSVM requires in order to operate correctly. In particular, get_pages() relies on hmm_range_fault() to resolve struct pages for the target range. Attempting to create an SVM range on such VMAs results in repeated get_pages() failures and can lead to an infinite loop inside a driver’s page‑fault handler. Prevent this by rejecting ranges on VM_IO or VM_PFNMAP VMAs and returning -EIO. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260325231608.25581-1-matthew.brost@intel.com Signed-off-by: Sasha Levin commit 3e61215a443b45c7134c816ca80ab02ec1083055 Author: Tomi Valkeinen Date: Wed Mar 11 11:14:43 2026 +0200 drm/tidss: Drop extra drm_mode_config_reset() call [ Upstream commit f468fef38716f667e805e0fa2c497c6b9c325bb9 ] We are calling drm_mode_config_reset() twice at probe time. There's no reason for this and the second call can be removed, reducing work at probe time slightly. Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260311-tidss-minor-fixes-v2-1-cb4479784458@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 13e587aa74a5f80f67f4671b36828227666fd011 Author: Thomas Zimmermann Date: Fri Feb 27 14:31:10 2026 +0100 drm/rockchip: Test for imported buffers with drm_gem_is_imported() [ Upstream commit 9fc0da81916250f343599a4dd259f097196bf0fb ] Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann Cc: Sandy Huang Cc: Heiko Stübner Cc: Andy Yan Cc: linux-rockchip@lists.infradead.org Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andyshrk@163.com/ Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260227133113.235940-11-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 33bc9fba3ae05863fabe3436ddca2ca4f4939c5e Author: Cristian Ciocaltea Date: Tue Mar 10 00:44:31 2026 +0200 drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove() [ Upstream commit 9456381d8b60bb7dd42f2f04afe5ee4ce6e0bc12 ] Attempting to access driver data in the platform driver ->remove() callback may lead to a null pointer dereference since there is no guaranty that the component ->bind() callback invoking platform_set_drvdata() was executed. A common scenario is when Rockchip DRM driver didn't manage to run component_bind_all() because of an (unrelated) error causing early return from rockchip_drm_bind(). Drop the unnecessary call to platform_get_drvdata() and, instead, reference the target device structure via platform_device. Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260310-drm-rk-fixes-v2-3-645ecfb43f49@collabora.com Signed-off-by: Sasha Levin commit 6b0b92d1110eccccbd5ba2949bd2b9fb6ea5fc12 Author: Cristian Ciocaltea Date: Tue Mar 10 00:44:30 2026 +0200 drm/rockchip: dw_dp: Switch to drmm_kzalloc() [ Upstream commit ed9da8d23020352ad24c528db09b5acdd78b81fd ] Driver makes use of drmm_encoder_init() to initialize the encoder and automatically handle the cleanup by registering drm_encoder_cleanup() with drmm_add_action(). However, the internal structure containing the encoder part gets allocated with devm_kzalloc(), which happens while component_bind_all() is being called from Rockchip DRM driver. The component framework further ensures it is deallocated as part of releasing all the resources claimed during bind, which is triggered from component_unbind_all(). When the reference to the DRM device gets eventually dropped via drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release() attempts to access the now released encoder structure, leading to use-after-free. Ensure driver's internal structure is still reachable on encoder cleanup by switching from a device-managed allocation to a drm-managed one. Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260310-drm-rk-fixes-v2-2-645ecfb43f49@collabora.com Signed-off-by: Sasha Levin commit 195ab348af4b2bdf5988f9397059317bb68fd797 Author: Cristian Ciocaltea Date: Tue Mar 10 00:44:29 2026 +0200 drm/rockchip: inno-hdmi: Switch to drmm_kzalloc() [ Upstream commit 3cc50e7f73fcf79f28660b9d91566b13cb62e520 ] Driver makes use of drmm_encoder_init() to initialize the encoder and automatically handle the cleanup by registering drm_encoder_cleanup() with drmm_add_action(). However, the internal structure containing the encoder part gets allocated with devm_kzalloc(), which happens while component_bind_all() is being called from Rockchip DRM driver. The component framework further ensures it is deallocated as part of releasing all the resources claimed during bind, which is triggered from component_unbind_all(). When the reference to the DRM device gets eventually dropped via drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release() attempts to access the now released encoder structure, leading to use-after-free. Ensure driver's internal structure is still reachable on encoder cleanup by switching from a device-managed allocation to a drm-managed one. Fixes: 969325a2597e ("drm/rockchip: inno-hdmi: Convert to drm bridge") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260310-drm-rk-fixes-v2-1-645ecfb43f49@collabora.com Signed-off-by: Sasha Levin commit 5b24e0903c58cdfd8ebfecb6ac5c5bacfd06e4e7 Author: Max Zhen Date: Wed Mar 25 18:06:42 2026 -0700 accel/amdxdna: Fix leak when pinning ubuf pages [ Upstream commit d946347edc4f0a7b846325323d77e936a4c90d0f ] When pin_user_pages_fast() returns fewer pages than requested, the pages that were successfully pinned are not released, leading to a leak. Fix this by unpinning any partially pinned pages before returning failure. Fixes: bd72d4acda10 ("accel/amdxdna: Support user space allocated buffer") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260326010642.2596525-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 70df8141a83c8dbcee2cd611229c1b6cd3f29a28 Author: Chen Ni Date: Thu Feb 5 16:40:37 2026 +0800 clocksource/drivers/sun5i: Handle error returns from devm_reset_control_get_optional_exclusive() [ Upstream commit fed9f727cc3f91dde8278961269419083502b40e ] The devm_reset_control_get_optional_exclusive() function may return an ERR_PTR in case of genuine reset control acquisition errors, not just NULL which indicates the legitimate absence of an optional reset. Add an IS_ERR() check after the call in sun5i_timer_probe(). On error, return the error code to ensure proper failure handling rather than proceeding with invalid pointers. Fixes: 7e5bac610d2f ("clocksource/drivers/sun5i: Convert to platform device driver") Signed-off-by: Chen Ni Signed-off-by: Daniel Lezcano Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260205084037.3661261-1-nichen@iscas.ac.cn Signed-off-by: Sasha Levin commit 5eabaad3008f98f7029a8c6e44933ca52df7e8b9 Author: Stafford Horne Date: Sat Mar 21 09:22:05 2026 +0000 openrisc: mm: Fix section mismatch between map_page and __set_fixmap [ Upstream commit 431400d49cac4bac944fc2d989921003314667ae ] This warning was reported by the kernel test robot: WARNING: modpost: vmlinux: section mismatch in reference: __set_fixmap+0x84 (section: .text.unlikely) -> map_page.isra.0 (section: .init.text) With commit 4735037b5d9b ("openrisc: Add text patching API support") the __set_fixmap function was moved out of the .init.text section. However, the map_page helper that it uses was not moved. This was not noticed on gcc 15.1.0 where map_page gets inlined unlike lkp@intel.com which uses gcc 10.5.0. Fix this by also moving the map_page helper function out of the init section. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603211503.E8mMETO3-lkp@intel.com/ Fixes: 4735037b5d9b ("openrisc: Add text patching API support") Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 3be3d05bb5acf91b759a24cbd0b171571d392ae2 Author: Felix Gu Date: Tue Mar 10 00:25:30 2026 +0800 soc: fsl: qe_ports_ic: Add missing cleanup on device removal [ Upstream commit 7dad18a179741dbad9f40799e549fa9111987c0c ] Add a devm action handler to properly clean up the irq_domain and chained handler when the device is removed. Fixes: f0bcd784e1b7 ("soc: fsl: qe: Add an interrupt controller for QUICC Engine Ports") Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/20260310-qe_ports_ic-v1-1-608293026561@gmail.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 18f901565ec18c56ccf89e1bd2cbc8abf6b0340b Author: Jiacheng Yu Date: Thu May 14 17:19:18 2026 +0800 fbcon: Use correct type for vc_resize() return value commit 84202754fb1727dc3ee87f47104e4162ecc8ba3a upstream. The return value of vc_resize() is int, but fbcon_set_disp() stores it in an unsigned long variable. While the !ret check happens to work correctly by coincidence (negative values become large positive values), the types should match. Use int instead. Eliminates the following W=3 warning: drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_disp': drivers/video/fbdev/core/fbcon.c:1494:14: warning: implicit conversion from 'int' to 'unsigned long' [-Wconversion] Fixes: af0db3c1f898 ("fbdev: Fix vmalloc out-of-bounds write in fast_imageblit") Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Jiacheng Yu Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit b134ad2f7c06b3c1098dcc95008e2045ff4b49b2 Author: Ian Bridges Date: Wed Jun 24 16:11:36 2026 -0500 fbcon: fix NULL pointer dereference for a console without vc_data commit 5fae9a928482d4845bca169a3a098789203a1ca4 upstream. fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles. Reported-by: syzbot+42525d636f430fd5d983@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=42525d636f430fd5d983 Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Ian Bridges Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit d14e96ddd616c8a9fff3b5bab3bf4af0cfc30ec4 Author: David Howells Date: Wed Jun 24 17:38:12 2026 +0100 afs: Fix uncancelled rxrpc OOB message handler commit a4057e58b07005d0fe0491bdbf1868c1491909ee upstream. Fix AFS to cancel its OOB message processing (typically to respond to security challenges). Also move OOB message processing to afs_wq so that it's also waited for and make the OOB handler just return if the net namespace is no longer live. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Li Daming cc: Ren Wei cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c6a1bc2fbd14844c2050cf615a6f3537f547fcb0 Author: David Howells Date: Wed Jun 24 17:38:11 2026 +0100 afs: Fix further netns teardown to cancel the preallocation charger commit 2daf8ac812c3d78c642fe7652f62e29df5e3da20 upstream. When an afs network namespace is torn down, it cancels and waits for the work item that keeps the preallocated rxrpc call/conn/peer queue charged before disabling incoming (i.e. listen 0), but there's a small window in which it can be requeued by an incoming call wending through the I/O thread. Fix this by cancelling the charger work item again after reducing the listen backlog to zero. Fixes: 47694fbc9d24 ("afs: Fix netns teardown to cancel the preallocation charger") Reported-by: Jakub Kicinski Signed-off-by: David Howells Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com cc: Li Daming cc: Ren Wei cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0bd5f2786a878148190b4c7c259d01313d5f2357 Author: Nan Li Date: Mon Jun 22 10:08:35 2026 +0100 afs: handle CB.InitCallBackState3 requests without a server record commit f3cf725cd284b7912d5522babb44721bf38c8887 upstream. The cache manager callback path now attaches the server record to an incoming call through the rxrpc peer's app data. That association is not guaranteed to exist for every callback request, and most callback handlers already tolerate that case. Make CB.InitCallBackState3 follow the same pattern by checking whether a server record was attached before using it. If the peer is not mapped to a server record, trace the request and ignore it, matching the existing behaviour for other unmatched callback requests. This keeps the callback handler consistent with the rest of the cache manager service and avoids depending on peer state that may not be available for a given request. Fixes: 40e8b52fe8c8 ("afs: Use the per-peer app data provided by rxrpc") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Nan Li Signed-off-by: Ren Wei Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-2-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 70b2842734d831c908474779bb8a76daf55f782c Author: Matvey Kovalev Date: Mon Jun 22 10:08:37 2026 +0100 afs: fix NULL pointer dereference in afs_get_tree() commit 0b70716081c6462be9b2928ad736d0d527b09678 upstream. afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 80548b03991f5 ("afs: Add more tracepoints") Cc: stable@vger.kernel.org Signed-off-by: Matvey Kovalev Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-4-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit eec89c5f8e1adc1de4824042ef75f62aed804153 Author: David Howells Date: Tue Jun 9 15:09:08 2026 +0100 afs: Fix netns teardown to cancel the preallocation charger commit 47694fbc9d24ab6bf210f91e8efe06a10a478064 upstream. Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review). Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Simon Horman Signed-off-by: David Howells cc: Li Daming cc: Ren Wei cc: Marc Dionne cc: Jeffrey Altman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1297ae6aeebc3863cb437e42a1bc4cd6173e43d9 Author: David Howells Date: Wed Jun 24 17:38:10 2026 +0100 rxrpc: Fix double unlock in rxrpc_recvmsg() commit a2f299b4d5510147fa8629a6aba2869bbcc88aea upstream. Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4d61b096fd744b61ba8e8601fe8c99c3afce74ed Author: David Howells Date: Wed Jun 24 17:38:09 2026 +0100 rxrpc: Fix leak of connection from OOB challenge commit 4b28876e78fd60979afa91fd2ec6ad9cc8b7a6d0 upstream. Fix leak of connection object from OOB challenge queue when response is provided by userspace. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e220ae559e5a0fc33e41ec6a348ea50387cb8b0f Author: David Howells Date: Wed Jun 24 17:38:13 2026 +0100 rxrpc: Fix the reception of a reply packet before data transmission commit a58e33405acd2584e730c1da72635f822ada6b49 upstream. Fix rxrpc_receiving_reply() to handle the reception of an apparent reply DATA packet before rxrpc has had a chance to send any request DATA packets on a client call by checking to see if the call has been exposed yet by sending the first packet. Without this, rxrpc_rotate_tx_window() might oops. Also fix rxrpc_rotate_tx_window() to handle the Tx queue being empty by changing the do...while loop into a while loop, just in case a call is abnormally terminated by an early reply before the last request packet is transmitted. Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct") Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-7-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 523cb585672ae681b2d3b0d620aec5313774e2e2 Author: Wyatt Feng Date: Wed Jun 24 17:38:08 2026 +0100 rxrpc: Fix ACKALL packet handling commit 9b6ce594808580b2a19e6e1aa459ef56c0153ac1 upstream. rxrpc_input_ackall() accepts ACKALL packets without checking whether the call is in a state that can legitimately have outstanding transmit buffers. A forged ACKALL can therefore reach a new service call in RXRPC_CALL_SERVER_RECV_REQUEST before any reply packets have been queued. In that state call->tx_top is zero and call->tx_queue is NULL, so rxrpc_rotate_tx_window() dereferences a NULL txqueue and triggers a null-pointer dereference. Fix the handling of ACKALL packets by the following means: (1) Add two new call states: RXRPC_CALL_CLIENT_PRE_SEND which indicates that the client call is connected, but nothing has been transmitted as yet; and RXRPC_CALL_CLIENT_AWAIT_ACK, which indicates that everything has been transmitted at least once, but we're now waiting for the stuff remaining in the Tx buffer to be ACK'd (retransmissions may still happen). The RXRPC_CALL_CLIENT_PRE_SEND state is set when the call is assigned a channel and transitions to RXRPC_CALL_CLIENT_SEND_REQUEST when the first packet is transmitted. RXRPC_CALL_CLIENT_AWAIT_REPLY is then narrowed in scope to indicate that all Tx packets have been ACK'd and we're now waiting for the reply to be received. (2) As per Wyatt Feng's original patch[1], the ACKALL handler then checks that the call state is one in which there might be stuff in the Tx buffer to ACK, but now this includes AWAIT_ACK rather than AWAIT_REPLY. ACKALL packets are ignored if received in the wrong state. Note that unlike Wyatt Feng's patch, it's no longer necessary to check to see if the Tx buffer exists as this the state set now covers this. (3) Make the ACKALL handler use call->tx_transmitted rather than call->tx_top as the former is explicitly the highest packet seq number transmitted, whereas the latter has a looser definition. Thanks to Jeffrey Altman for a description of the history of the ACKALL packet[1]. Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Wyatt Feng Co-developed-by: David Howells Signed-off-by: David Howells cc: Ren Wei cc: Marc Dionne cc: linux-afs@lists.infradead.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260616155749.2125907-2-dhowells@redhat.com/ [1] Link: https://lore.kernel.org/r/c0fd4fec-1576-4070-b31e-a37d5506f5ed@auristor.com/ [2] Reviewed-by: Jeffrey Altman Link: https://patch.msgid.link/20260624163819.3017002-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e0ca365f2101384bb061b4e5292faf1e6bd4c245 Author: David Howells Date: Wed Jun 24 17:38:14 2026 +0100 rxrpc: Fix oob challenge leak in cleanup after notification failure commit 092275882aec4a70ba55c3efb66fff947c81656a upstream. Fix rxrpc_notify_socket_oob() to return an indication of failure in the event that it failed to queue a packet and fix rxrpc_post_challenge() to clean up the connection ref in such an event. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-8-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit af107968bc3a4cda67fc54b1a2d3ef25ab050c4e Author: David Howells Date: Wed Jun 24 17:38:18 2026 +0100 rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate commit a5462da5a349fc7f17ad5ebd899380260d03e7ed upstream. Fix rxrpc_rotate_tx_rotate() to check that there's something in the transmission buffer to be rotated before it attempts to rotate anything. Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct") Link: https://sashiko.dev/#/patchset/20260618134802.2477777-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-12-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit da371b003a4a44f44741275d5e8dc74181cbb017 Author: David Howells Date: Wed Jun 24 17:38:15 2026 +0100 rxrpc: Fix potential infinite loop in rxrpc_recvmsg() commit 67a0332f442ef07713cd2d9c13d59db0f1c23648 upstream. Fix the wait in rxrpc_recvmsg() also take check the oob queue. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-9-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 04c7103dc0923cc6ac95b97aa66bab70da7ace84 Author: David Howells Date: Wed Jun 24 17:38:17 2026 +0100 rxrpc: Fix leak of released call in recvmsg(MSG_PEEK) commit 4bdb9e471f5b1ac9cbe4add5de7ff085a0ec303c upstream. Fix rxrpc_recvmsg() to also drop the ref it holds on an already-released call if MSG_PEEK is in force (the function holds a ref on the call irrespective of whether MSG_PEEK is specified or not). Fixes: 962fb1f651c2 ("rxrpc: Fix recv-recv race of completed call") Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-11-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea5aca7a64e111558ff7ffc3ef8b67444ca9b840 Author: David Howells Date: Wed Jun 24 17:38:16 2026 +0100 rxrpc: Fix socket notification race commit e66f8f32f50116670dbbee5bc9e692cd2cd0c8f8 upstream. There's a race between rxrpc_recvmsg() and rxrpc_notify_socket(), whereby the latter's attempt to avoid disabling interrupts and taking the socket's recvmsg_lock if the call is already queued may happen simultaneously with the former's discarding of a call that has nothing queued. Fix this by removing the shortcut. Note that this only affects userspace's use of AF_RXRPC; the AFS filesystem driver doesn't use the socket queue. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-10-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 83bb0ed050e2ad9453d8ef50e4d6e624eac6eed8 Author: David Howells Date: Tue Jun 9 15:09:07 2026 +0100 rxrpc: Fix UAF in rxgk_issue_challenge() commit 107a4cb0d47e735830f852d83970d5c81f8e1e08 upstream. Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Reported-by: Marc Dionne Signed-off-by: David Howells cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5f470cc883416fea6d3bce18ef96bf91dd49ffc3 Author: Hyunwoo Kim Date: Tue Jun 9 15:09:06 2026 +0100 rxrpc: Don't move a peeked OOB message onto the pending queue commit 5801cff7d5d7b4e9d877dfb627b23eb63167f02c upstream. rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Signed-off-by: Hyunwoo Kim Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a962bc8508592c4d51092edac68579bd8b18fe44 Author: Jeffrey Altman Date: Tue Jun 9 15:09:05 2026 +0100 rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc commit 16c8ae9735c5bd7e54dd7478d6348e0fc860842d upstream. rxrpc_recvmsg_data() calls rxrpc_verify_data() whenever the rxrpc_call.rx_dec_buffer is unallocated and assumes that upon successful return that rx_dec_buffer must be allocated. However, rxrpc_verify_data() does not request an allocation if the rxrpc_skb_priv.len is zero. In addition, failure to allocate rx_dec_buffer will result in a call to skb_copy_bits() with a NULL destination which can trigger a NULL pointer dereference. To prevent these issues rxrpc_verify_data() is modified to always attempt to allocate the rxrpc_call.rx_dec_buffer if it is NULL. This issue was identified with assistance of a private sashiko instance. Fixes: d2bc90cf6c75cb ("rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg") Reported-by: Simon Horman Signed-off-by: Jeffrey Altman Signed-off-by: David Howells cc: Jiayuan Chen cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1741378a7a83dfd8e53a9196730df709b903cd33 Author: Li Daming Date: Tue Jun 9 15:09:09 2026 +0100 rxrpc: serialize kernel accept preallocation with socket teardown commit dc175389b18c29a5303ee83169ec653adfae3e17 upstream. rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog. Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Li Daming Signed-off-by: Ren Wei Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit df1fbb25afc1c82af934c1c0326a9c0ec07f7ad8 Author: Matthias Feser Date: Tue May 26 07:35:09 2026 +0000 serial: 8250_omap: clear rx_running on zero-length DMA completes commit 061b627ba534230a18ec4d7251562af12325d06a upstream. On AM33xx RX DMA only triggers when the FIFO reaches the configured threshold (typically 48 bytes). For smaller bursts no DMA request is issued and the FIFO is drained by RX timeout. In this case __dma_rx_do_complete() can legitimately see count == 0. The current code exits early in this case and does not clear dma->rx_running, leaving the DMA state inconsistent. This can prevent RX DMA from restarting and may cause omap_8250_rx_dma_flush() to fail, marking DMA as broken. Fix this by clearing dma->rx_running once the DMA transfer has completed or been terminated, even if no data was transferred. Fixes: a5fd8945a478 ("serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done") Cc: stable Signed-off-by: Matthias Feser Reviewed-by: Moteen Shah Link: https://patch.msgid.link/BE3P281MB55155F2F5795E411F5A65282EE0B2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 229815484518a34d731675143d59c435428bb932 Author: Tapio Reijonen Date: Mon Jun 15 06:38:40 2026 +0000 serial: max310x: implement gpio_chip::get_direction() commit a483b1a91b33b7533280e7c3efd2bc1275caef18 upstream. It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit selects output), which the existing direction_input/output callbacks already program, so the current direction can be read back directly. Fixes: f65444187a66 ("serial: New serial driver MAX310X") Cc: stable Signed-off-by: Tapio Reijonen Reviewed-by: Linus Walleij Reviewed-by: Bartosz Golaszewski Reviewed-by: Hugo Villeneuve Link: https://patch.msgid.link/20260615-b4-serial-max310x-gpio-get-direction-v2-1-4704ba2b181a@vaisala.com Signed-off-by: Greg Kroah-Hartman commit e3b42e326f4f30efcdc90bad5f5ba37e1cd91a47 Author: Stephan Gerhold Date: Mon Jul 6 20:03:32 2026 +0200 serial: msm: Disable DMA for kernel console UART commit 22dd2777e6c180e1c945b00f6d18550979436324 upstream. At the moment, concurrent writes from userspace and the kernel to the console can trigger a race condition that results in an infinite loop of the same messages printed over and over again. This is most likely to happen during system startup or shutdown when the init system starts/stops a large number of system services that interact with various kernel code. When userspace writes to the TTY device, the driver initiates an asynchronous DMA transfer and releases the port lock. At the same moment, the kernel printk path might grab the port lock and re-configure the UART controller for PIO, without waiting for the DMA operation to complete. It seems like this collision results in zero progress being reported for the DMA engine, so the same text is printed to the console over and over again. For the kernel console, we want a reliable output path that will be functional even during crashes etc. So rather than implementing complex code to synchronize the kernel console write routines with the userspace DMA write routines, simply disable DMA for the console UART instance. Similar checks exist in many other serial drivers, e.g. 8250_port.c, imx.c, sh-sci.c etc. Cc: stable Fixes: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") Signed-off-by: Stephan Gerhold Acked-by: Konrad Dybcio Link: https://patch.msgid.link/20260706-serial-msm-console-dma-collision-v1-1-3179b8cb1d89@linaro.org Signed-off-by: Greg Kroah-Hartman commit 85af1567f67a90dc3bc401ac9d1402e9512e7e84 Author: Guoniu Zhou Date: Tue Jun 9 14:26:40 2026 +0800 dt-bindings: power: imx93: Add MIPI PHY power domain commit 6aa38ef0eab32df5409b72d62509de6ba09cea50 upstream. Add MIPI PHY power domain for shared PHY resources used by both MIPI DSI and CSI blocks. Signed-off-by: Guoniu Zhou Reviewed-by: Frank Li Acked-by: Krzysztof Kozlowski Reviewed-by: Peng Fan Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7b3027722ab87d33ff28b967dd353ac76998e255 Author: Chen-Yu Tsai Date: Thu Dec 25 18:36:12 2025 +0800 dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties commit 018f2dc3a42098d3b04edd1480adc51d268adb14 upstream. The Allwinner video engine sits behind the MBUS that is represented as an interconnect. Make sure that the interconnect properties are valid in the binding. Fixes: d41662e52a03 ("media: dt-bindings: media: allwinner,sun4i-a10-video-engine: Add R40 compatible") Cc: stable@vger.kernel.org Signed-off-by: Chen-Yu Tsai Acked-by: Rob Herring (Arm) Acked-by: Jernej Skrabec Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cf5f54c018967394f54ea196a98f4f016f70eb89 Author: Ricardo Ribalda Date: Mon Mar 23 09:53:52 2026 +0000 media: uvcvideo: Fix sequence number when no EOF commit f078966ca1fb1b3865d8e6bbe2705cfd277fc637 upstream. If the driver could not detect the EOF, the sequence number is increased twice: 1) When we enter uvc_video_decode_start() with the old buffer and FID has flipped => We return -EAGAIN and last_fid is not flipped 2) When we enter uvc_video_decode_start() with the new buffer. Fix this issue by moving the new frame detection logic earlier in uvc_video_decode_start(). This also has some nice side affects: - The error status from the new packet will no longer get propagated to the previous frame-buffer. - uvc_video_clock_decode() will no longer update the previous frame buf->stf with info from the new packet. - uvc_video_clock_decode() and uvc_video_stats_decode() will no longer get called twice for the same packet. Cc: stable@kernel.org Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost") Reported-by: Hans de Goede Closes: https://lore.kernel.org/linux-media/CANiDSCuj4cPuB5_v2xyvAagA5FjoN8V5scXiFFOeD3aKDMqkCg@mail.gmail.com/T/#me39fb134e8c2c085567a31548c3403eb639625e4 Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f3970948369e41569a566fb37615c64e397661c8 Author: Ricardo Ribalda Date: Wed May 13 11:49:22 2026 +0000 media: uvcvideo: Relax the constrains for interpolating the hw clock commit 1719d78f832dda8dd3f09a867ba74e05d6f11308 upstream. In the initial version we set the min value to 250msec. Looks like 100msec can also provide a good value. Now that we are at it, add a macro to make it cleaner. Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Yunke Cao Signed-off-by: Ricardo Ribalda Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-3-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 600e379bd5891ff1d530418b5a0513c981157aa8 Author: Ricardo Ribalda Date: Wed May 13 11:49:23 2026 +0000 media: uvcvideo: Do not add clock samples with small sof delta commit ba649fff36c1fe68489a86d00285224907edd436 upstream. Some UVC 1.1 cameras running in fast isochronous mode tend to spam the USB host with a lot of empty packets. These packets contain clock information and are added to the clock buffer but do not add any accuracy to the calculation. In fact, it is quite the opposite, in our calculations, only the first and the last timestamp is used, and we only have 32 slots. Ignore the samples that will produce less than MIN_HW_TIMESTAMP_DIFF data. Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer") Cc: stable@vger.kernel.org Tested-by: Yunke Cao Reviewed-by: Hans de Goede Signed-off-by: Ricardo Ribalda Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-4-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 40aaf991dc0a7928b72500d3119c974956aa8216 Author: Ricardo Ribalda Date: Wed May 13 11:49:20 2026 +0000 media: uvcvideo: Fix dev_sof filtering in hw timestamp commit edc1917599c5339aedc83135cade66517e0a2972 upstream. To avoid filling the clock circular buffer with duplicated data we only add it if the new value sof is different than the last added sof. The issue is that we compare the unprocess sof with the processed sof. If there is a sof_offset, or UVC_QUIRK_INVALID_DEVICE_SOF is enabled, the comparison will not work as expected. This patch moves the comparison to the right place. Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Yunke Cao Signed-off-by: Ricardo Ribalda Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-1-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c082b0ed2db6d6f9e369f1855cfbef78cc7bb205 Author: Ricardo Ribalda Date: Mon Mar 23 09:53:53 2026 +0000 media: uvcvideo: Fix buffer sequence in frame gaps commit 2f24ac8dd87983a55f0498898f34a5f2b735b802 upstream. In UVC, the FID flips with every frame. For every FID flip, we increase the stream sequence number. Now, if a FID flips multiple times and there is no data transferred between the flips, the buffer sequence number will be set to the value of the stream sequence number after the first flip. Userspace uses the buffer sequence number to determine if there have been missing frames. With the current behaviour, userspace will think that the gap is in the wrong location. This patch modifies uvc_video_decode_start() to provide the correct buffer sequence number and timestamp. Cc: stable@kernel.org Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost") Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b058d9a21694466e83d4dc3213a94397c4d87ab8 Author: Ricardo Ribalda Date: Fri Apr 17 05:19:29 2026 +0000 media: uvcvideo: Avoid partial metadata buffers commit a15b773fe4ffa450b56347cc506b2d1405600f5d upstream. If the metadata queue that is empty receives a new buffer while we are in the middle of processing a frame, the first metadata buffer will contain partial information. Avoid this by tracking the state of the metadata buffer and making sure that it is in sync with the data buffer. Now that we are at it, make sure that we skip buffers of size 1 or 0. They are not allowed by the spec... but it is a simple check to add and better be safe than sorry. Fixes: 088ead255245 ("media: uvcvideo: Add a metadata device node") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Link: https://patch.msgid.link/20260417-uvc-meta-partial-v2-2-31d274af7d2d@chromium.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ca4c918226845ea3ea2c60e538f7e5920d25207a Author: Ricardo Ribalda Date: Wed May 13 11:49:21 2026 +0000 media: uvcvideo: Use hw timestaming if the clock buffer is full commit ede7de6e6b3db552d10ac50557d69c50d1b08486 upstream. In some situations, even with a full clock buffer, it does not contain 250msec of data. This results in the driver jumping back from software to hardware timestapsing creating a nasty artifact in the video. If the clock buffer is full, use it to calculate the timestamp instead of defaulting to software stamps, the reduced accuracy is less visible than jumping from one timestamping mechanism to the other. Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Yunke Cao Signed-off-by: Ricardo Ribalda Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-2-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9ba2fd1433170ed95fc98c51cb7171e3a29e498a Author: Damien Laine Date: Sun Jul 12 23:37:08 2026 +0200 ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID 17aa:38a7 commit d35dfb6329accfe1cfa0b57e35214b5cbbe0f9ae upstream. Some units of the Lenovo Legion Pro 7 16ARX8H (82WS) report codec subsystem ID 17aa:38a7 instead of 17aa:38a8. Since only 38a8 has a codec SSID quirk, these machines fall through to the PCI SSID match 17aa:386f (Legion Pro 7i 16IAX7) and get ALC287_FIXUP_CS35L41_I2C_2, which probes the Cirrus amplifiers of the Intel variant. The TI TAS2781 amplifier (ACPI TIAS2781:00) present on this AMD variant is never bound and the internal speakers remain silent. Add a codec SSID quirk for 17aa:38a7 pointing to ALC287_FIXUP_TAS2781_I2C, mirroring the existing 38a8 entry. Tested on a Legion Pro 7 16ARX8H (82WS, BIOS LPCN62WW): with the codec SSID overridden to 17aa:38a8 via the HDA patch loader, the TAS2781 amplifier binds and the internal speakers work. Cc: Signed-off-by: Damien Laine Link: https://patch.msgid.link/20260712213708.1835469-1-damien.laine@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ba68c540dafb73bb1ae01b5901ed58b76311528f Author: Xu Rao Date: Tue Jul 7 21:24:19 2026 +0800 ALSA: hda: Fix cached processing coefficient verbs commit f67be28fdf8b5d31ac1cc1152bb17250f9f8f513 upstream. Intel HD Audio defines Coefficient Index and Processing Coefficient as separate audio widget controls in the Audio Widget Verb Definitions: Coefficient Index selects the coefficient slot, while Processing Coefficient accesses the value at the selected slot. hda_reg_read_coef() selects the slot with AC_VERB_SET_COEF_INDEX, but then uses AC_VERB_GET_COEF_INDEX for the value read. That reads back the selected index instead of the coefficient value. hda_reg_write_coef() has the same issue and builds the value write from AC_VERB_GET_COEF_INDEX instead of AC_VERB_SET_PROC_COEF. This only affects the regmap coefficient cache path used by codecs that set codec->cache_coef. Direct coefficient helpers already use the normal SET_COEF_INDEX followed by GET_PROC_COEF or SET_PROC_COEF sequence, which is likely why this has not been noticed widely. Use AC_VERB_GET_PROC_COEF for cached coefficient reads and AC_VERB_SET_PROC_COEF for cached coefficient writes. Fixes: 40ba66a702b8 ("ALSA: hda - Add cache support for COEF read/write") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/DB9023BF2920BA99+20260707132419.1731342-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 30469715fbfefe12e36f0c72da7f5531c669e1f4 Author: Zhang Heng Date: Mon Jul 13 18:03:29 2026 +0800 ALSA: hda: conexant: Remove mic bias threshold override commit f52524da7084c1a54683ae9fbc73e93fff19dd64 upstream. Remove the mic bias current comparator threshold override (NID 0x1c, verb 0x320, value 0x010) from Conexant codec driver. This override was originally intended to support volume up/down controls on headsets with inline remote controls, but it causes microphone detection failures on some headsets with impedance less than 1k ohm. After consulting with the vendor's engineers, it was confirmed that this setting is board-specific and should be handled by BIOS/firmware rather than the generic codec driver, especially since inline remote support is not currently implemented. Fixes: 7aeb25908648 ("ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140") Cc: stable@vger.kernel.org Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260713100329.306892-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 63c5a6766701b6c27545cdc23bb5ecf2e36d269d Author: Eckhart Mohr Date: Wed Jul 8 15:21:06 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang X6xx45xU commit d595255241e5fec0c94adeebf2565524398e37c5 upstream. Fix microphone detection on built in headphone jack for some devices. Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260708132135.102680-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7f6c5fe1633272c926361b73d83dfc6ae01b1504 Author: Sean Anderson Date: Mon Mar 16 11:58:22 2026 -0400 media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work [ Upstream commit 6d27f92c54ce28cfbd2a8a479a96d6f4a781b7d2 ] If a UVC camera has an asynchronous control, uvc_status_stop may be called from async_ctrl.work: uvc_ctrl_status_event_work() uvc_ctrl_status_event() uvc_ctrl_clear_handle() uvc_pm_put() uvc_status_put() uvc_status_stop() cancel_work_sync() This will cause a deadlock, since cancel_work_sync will wait for uvc_ctrl_status_event_work to complete before returning. Fix this by returning early from uvc_status_stop if we are currently in the work function. flush_status now remains false until uvc_status_start is called again, ensuring that uvc_ctrl_status_event_work won't resubmit the URB. Fixes: a32d9c41bdb8 ("media: uvcvideo: Make power management granular") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/6733bdfb-3e88-479f-8956-ab09c04c433e@linux.dev/ Signed-off-by: Sean Anderson Link: https://patch.msgid.link/20260316155823.1855434-1-sean.anderson@linux.dev Reviewed-by: Ricardo Ribalda Tested-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9c8086d9511189c34dfa3f9e3a03f2bee12f56a5 Author: Eric Biggers Date: Thu Jul 16 20:50:58 2026 -0700 crypto: sun4i-ss - Remove insecure and unused rng_alg commit b2c41fa9dd8fc740c489e060b199165771f268d1 upstream. Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the "rng" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it. Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG") Cc: stable@vger.kernel.org Reported-by: Tianchu Chen Closes: https://lore.kernel.org/r/af749a8447bd7f0e9dd26ca6c87e9c6afecb09d9@linux.dev/ Acked-by: Corentin LABBE Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7fd4077dc92b91b1b844333c0a06bb9e286db10a Author: Michael Bommarito Date: Thu Jun 4 14:03:07 2026 +0800 iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry [ Upstream commit f46452c3df7a8d8a5addc0926e76ef19ea7da0a0 ] device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d ("iommu/vt-d: Clear Present bit before tearing down context entry") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the "Guidance to Software for Invalidations" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry. Fixes: 81e921fd32161 ("iommu/vt-d: Fix NULL domain on device release") Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Link: https://lore.kernel.org/r/20260528025557.3209367-1-michael.bommarito@gmail.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b05defc41b27c7d0c05c45f67bf5b91c28f93669 Author: Muhammet Kaan KILINÇ Date: Thu Jul 16 02:58:36 2026 +0000 crypto: algif_skcipher - force synchronous processing The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously by a worker (e.g. cryptd), which dereferences ctx->iv only later. A concurrent sendmsg(ALG_SET_IV) on the same socket can overwrite ctx->iv inside this window, so the in-flight request runs under an attacker-controlled IV. For CTR and other stream modes this causes IV/keystream reuse and allows an unprivileged user to recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient here. For ciphers with statesize == 0 - which includes cbc and ctr - skcipher_prepare_alg() installs skcipher_noimport()/ skcipher_noexport(), so ctx->state carries nothing and the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback. A snapshot redirects that writeback into per-request memory that af_alg_free_resources() releases on completion, so AIO + MSG_MORE with cbc/ctr would silently produce wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead. ctx->iv is then only ever dereferenced under the socket lock held by recvmsg(), which removes the race, and the req->iv writeback lands in ctx->iv as before, which keeps MSG_MORE chaining intact for statesize == 0 ciphers. The ctx->state import/export path is unchanged for ciphers that do have state. This is equivalent to the upstream resolution: commit fcc77d33a34c ("net: Remove support for AIO on sockets") removed the AIO socket path across net/ entirely, producing the same end state for this file - algif_skcipher never processes an AIO request asynchronously. After this patch, _skcipher_recvmsg() matches mainline's crypto/algif_skcipher.c as it stands today, including the same now-dead -EIOCBQUEUED check. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously, which is valid for the AIO interface; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management") Cc: Reported-by: Muhammet Kaan KILINÇ Signed-off-by: Muhammet Kaan KILINÇ Signed-off-by: Sasha Levin